muse release channel 'rc' is valid client-side but rejected by the server (HTTP 409)

Summary

muse release add --channel accepts rc as a valid choice (it's documented in the CLI's own help text and in the auto-inference docstring: "-rc.* → rc"), but the MuseHub server's channel enum rejects it outright:

$ muse release push v0.2.1-rc1 --remote staging --json
❌ Push failed: HTTP 409: {"detail":"Unknown channel 'rc'. Choose: alpha, beta, nightly, stable"}

Impact

Found while cutting v0.2.1-rc1 for musehub staging #185's wrap-up. Had to delete and recreate the local release record with --channel beta to work around it — not semantically correct (beta and release-candidate are different maturity stages), just the closest accepted value.

Root cause (client/server enum drift)

The muse CLI's local channel inference/validation supports rc as a first-class channel (see muse release add --help and its auto-inference from -rc.* semver pre-release labels). The MuseHub server-side schema/validation for the release channel field does not include rc in its accepted set. One side needs to change — either:

• Add rc to the server's accepted channel enum (matches the CLI's existing behavior and semver convention: alpha < beta < rc < stable), or
• Remove rc from the CLI's inference/help text if rc is intentionally not a supported channel server-side.

Given the CLI already documents and infers rc as a real channel, and rc is a standard, meaningful release-maturity stage (distinct from beta), the server-side fix (add rc to the accepted enum) is very likely the correct direction — but worth confirming intent before assuming.

Suggested fix

Locate the server-side channel validation/enum (likely musehub/services/musehub_releases.py or the release Pydantic model) and add "rc" alongside alpha, beta, nightly, stable. Add a regression test creating a release with channel=rc and asserting it succeeds.