#311 Publish release-candidate / unstable extension versions

Problem

Every swamp extension push produces a stable, immediately-resolvable version. There's no channel for "candidate" or "preview" releases that consumers of swamp extension pull <name> (or auto-resolution against the registry) will skip by default.

This makes iterative CICD work and pre-release validation difficult:

• Pushing a candidate to verify it integrates correctly contaminates the stable channel — anyone running swamp extension pull <name> (including CI for other repos that depend on the extension) immediately picks up a not-yet-validated version.
• Fixing issues found during pre-release testing requires bumping the stable version each time, which clutters the version history and inflates the changelog with intermediate candidates that were never meant to be consumed.
• There's no way to "promote" a tested candidate to stable without re-pushing the same content under a new version number.

Proposed solution

Add release-channel support to swamp extension push and swamp extension pull:

1. Push side — a flag to mark a push as non-stable, e.g.

   • swamp extension push <manifest> --prerelease (defaults to a prerelease channel), or
   • swamp extension push <manifest> --tag rc (arbitrary channel name, à la npm dist-tags).

2. Pull / resolve side — by default, prereleases are invisible to:

   • swamp extension pull <name> (resolves to latest stable)
   • swamp extension search results
   • automatic resolution when running swamp model method run for a type whose extension isn't pulled

   Opt in explicitly with one of:

   • swamp extension pull <name>@rc (channel suffix), or
   • swamp extension pull <name> --prerelease / --tag rc (explicit flag).

3. Listing — swamp extension version <name> (and --json output) could surface both stable and per-channel latest versions so consumers know which is which.

4. Promotion — swamp extension promote <name> <version> (or similar) to move a tested prerelease to stable without re-uploading the tarball.

Alternatives considered

• Manual version naming (e.g. 2026.05.10.2-rc1) — doesn't help because the registry still treats it as "the latest version" for resolution. Plus CalVer + -rcN mixing breaks ordering.
• Per-collective stable channels — heavier change; a flag-based channel model is simpler and matches what npm/Cargo/pip already do.
• Don't push until validated — works only when validation can happen entirely on the publisher's machine; doesn't solve the cross-repo CI integration test scenario.

Example use case

Iterating on @hivemq/mudroom with new OpenTelemetry tracing:

1. swamp extension push extensions/models/mudroom/mudroom.manifest.yaml --prerelease
   • Publishes 2026.05.10.2 to the prerelease channel.
2. CI for a downstream consumer runs with --prerelease and exercises the new spans.
3. Issues found → fix, re-push as 2026.05.10.3 --prerelease. Stable channel still serves 2026.05.09.x to everyone else.
4. Once validated: swamp extension promote @hivemq/mudroom 2026.05.10.3 → 2026.05.10.3 becomes the stable resolution.

This mirrors how npm dist-tags, Cargo prereleases, and pip pre-release identifiers all work today.