Production install.sh is non-functional — no muse release tarball has ever been published to production

Summary

curl -fsSL https://musehub.ai/install.sh | sh does not work — production has never had a real muse release tarball published to it. install.sh's generated script displays whatever version musehub's own pyproject.toml reports (via the fallback path in _latest_published_muse_version()), but there is no actual file at https://musehub.ai/releases/muse-<version>.tar.gz to download, so a real install attempt 404s.

How this was found

While wrapping up musehub staging #185 and cutting v0.2.1-rc2, confirmed via SSM that production's /data/releases/ directory (inside the musehub_data Docker volume) has been completely empty since the account cutover on 2026-08-25 — this predates any of today's work. It was never a working install path.

Why it's not fixed yet

Per standing policy (confirmed with gabriel earlier in the #185 work): release candidates stay staging-only until they bake and are explicitly promoted. v0.2.1-rc2 is currently baking on staging — publishing an RC tarball to production would violate that policy, so this gap is being left alone deliberately for now, not overlooked.

What resolves this

Once v0.2.1-rc2 (or whatever's current at the time) is promoted to a stable, official release, run:

bash deploy/publish_muse_release.sh production

This script was built/parametrized for production support as part of #185 Phase 6 and has been verified mechanically ready (correct instance ID, correct Docker volume name, S3 bucket is public-read so no cross-account IAM changes needed) — it just hasn't been used for a real production publish yet, deliberately.

Acceptance criteria

• curl -sI https://musehub.ai/releases/muse-<version>.tar.gz returns 200, not 404.
• curl -fsSL https://musehub.ai/install.sh | sh succeeds end-to-end on a clean machine.
• The version displayed on /muse/getting-started matches the actual installable tarball (not just musehub's own fallback version string).