Adopt release-based production versions and a stable deployment channel #69

Goal

Replace commit-SHA-only production identification with explicit Marka releases while keeping immutable rollback artifacts. Initially support one release channel, stable.

Current state

• CI builds paired immutable images tagged web-sha-<commit> and workers-sha-<commit>.
• CI then promotes mutable web-main and workers-main tags: .github/workflows/docker.yml.
• Production Compose and the guided installer follow the main channel by default: deploy/docker-compose.prod.yml, scripts/install.sh.
• SERVER_VERSION, /api/version, and the PWA update identity currently derive from the Git commit: apps/web/next.config.mjs.
• The repository already contains multiple package version lines, so this issue should define the shared web, workers, production, and installer release contract without silently changing SDK, MCP, mobile, extension, or package publication versioning.

Release decisions

• Use one shared SemVer release for the web app, workers, production deployment, and guided installer, starting with tags such as v0.1.0.
• Create releases manually by pushing a version tag after the target commit has passed the required checks.
• Build paired immutable image tags such as web-v0.1.0 and workers-v0.1.0 from the same tagged commit.
• Promote paired mutable channel tags web-stable and workers-stable only after both images and release checks succeed.
• Keep the stable channel as the only supported release path for now. Do not add beta, nightly, candidate, or other channels in this issue.
• Show the release number and a short commit identifier in user-facing version surfaces and retain enough machine-readable metadata for exact provenance.

Scope

• Define the source of truth for the release version and validate vMAJOR.MINOR.PATCH tags.
• Add a tag-triggered release workflow that verifies the tagged commit is eligible, runs the required checks, builds web and workers from the same source, publishes immutable version tags, and promotes stable only after paired validation.
• Decide how GitHub Releases, release notes, and annotated tags relate, then document the maintainer procedure for creating the next release.
• Update production Compose, the guided installer, update commands, rollback instructions, and deployment documentation to use stable by default and immutable version tags for rollback.
• Replace or extend the current SHA-only SERVER_VERSION contract so /api/version, the PWA update logic, the sidebar version display, and mobile version checks expose both release and commit provenance without breaking existing clients.
• Preserve SHA-addressable image tags during the migration until version-tag rollback is verified.
• Add tests for tag validation, paired image naming, stable promotion, release metadata, rollback selection, and malformed or duplicate tags.

Non-goals

• Do not publish new beta or nightly channels.
• Do not automatically bump every workspace package version or change SDK, MCP, mobile, extension, or npm publishing semantics unless a separate release-policy issue is created.
• Do not make production depend on a mutable tag without retaining an immutable rollback reference.
• Do not mix release-channel changes with secret delivery or KARAKEEP_* compatibility renaming from #68.

Acceptance criteria

• A maintainer can create a documented vMAJOR.MINOR.PATCH tag from an eligible commit and obtain a corresponding GitHub Release.
• The workflow produces paired web-vX.Y.Z and workers-vX.Y.Z images from exactly one source commit.
• web-stable and workers-stable are promoted atomically or with a recovery procedure that prevents a web/workers version mismatch.
• Production Compose and the guided installer use the stable channel by default.
• A self-hosted operator can pin both services to one immutable release tag for rollback.
• /api/version, PWA update checks, sidebar version display, and mobile checks expose release plus short commit metadata consistently.
• Existing SHA-tag rollback remains available during the migration and is covered by tests or a verified procedure.
• Release documentation explains the difference between a Git tag, a GitHub Release, an immutable image tag, and the stable channel.