feat(sdk/typescript): publish @dagger.io/core as its own package - #15131

The package existed but nothing could ship it; it was built and published by
hand. This adds releaseCore alongside the SDK's own release, in the same shape:
build, set the version, publish, with a dry run as a check.

Its version is the **engine** release, so the tag is taken as-is rather than
through versionFromTag. The SDK is tagged sdk/typescript/vX and versioned on its
own cadence; core is the generated bindings for one engine, so the two move
together and nothing else here does.

@dagger.io/session is a published dependency now, so `npm install` fetches it
from the registry during the build. That is the point: it is the only step that
proves the package boundary holds before a tarball exists.

The prerelease channel decides the dist-tag, which is what keeps a beta engine
off `latest`. A non-semver tag falls back to "dev" because `npm version
prepatch` invents a prerelease and npm refuses to publish one under a name it
has never seen without a tag — which @dagger.io/core is, and which is why the
dry run failed until the fallback existed. The SDK's own release does not need
this: @dagger.io/dagger already exists, so npm does not ask.

Rehearsed against a local verdaccio: v1.0.0-beta.25 published under `beta`,
`latest` left where it was, session pinned at 1.0.0-beta.1, and the tarball
installs and loads with `dag` on it.

Signed-off-by: Tom Chauveau <tom@dagger.io>

core pinned @dagger.io/session at an exact version, which meant every session
release forced a core republish — and core's version is the engine's, so there
is often no version to republish it as.

Measured what the exact pin actually does. With core pinning 1.0.0-beta.1 and a
scope resolving session 1.0.0-beta.2, npm installs both:

  node_modules/@dagger.io/session                      -> 1.0.0-beta.2
  node_modules/@dagger.io/core/node_modules/@dagger.io/session -> 1.0.0-beta.1

That is not just a bigger tree. session carries ENGINE_VERSION and passes it as
--version when it starts a session, so core would keep announcing the older
engine while everything else announced the newer one — the bindings and the
served API drifting apart, which is the one thing the version coupling exists
to prevent.

With ^1.0.0-beta.1 the same install resolves to one copy. Verified both ways
against a local registry, and `^1.0.0-beta.1` matches 1.0.0-beta.2, 1.0.0 and
1.0.1 by semver.

Signed-off-by: Tom Chauveau <tom@dagger.io>

session, connect, module and telemetry are on 1.0.0-beta.2 now, and core was
still pinning beta.1 — which puts two copies of session in any scope that
resolves beta.2.

core cannot simply be republished: its version is the engine release and
1.0.0-beta.25 is taken. So this is a patch under that release, and the form
matters. `1.0.0-beta.25-2` would sort *above* every future beta, because
`25-2` is an alphanumeric prerelease identifier and alphanumeric outranks
numeric — semver puts it after 1.0.0-beta.26. `1.0.0-beta.25.2` sorts where it
should, between beta.25 and beta.26.

The session pin is a range now rather than exact, so the next session release
does not need another core patch.

Verified against real npmjs: it installs session 1.0.0-beta.2, tsc builds, and
the release dry run passes.

Signed-off-by: Tom Chauveau <tom@dagger.io>