feat(release): publish verified source tags

docs/RELEASE_CONSOLE.md

@@ -18,6 +18,8 @@ candidate/publish actions:
 - configure target versions per release unit in the web UI
 - select the repositories that should advance through checkboxes
 - generate dry-run selective release plans for independently versioned packages
+- create annotated source release tags for selected clean, version-aligned
+  repositories and publish each branch/tag pair atomically
 - generate signed catalog candidates for the selected release units
 - preview/apply/push reviewed catalog candidates behind explicit confirmations
 
@@ -56,13 +58,50 @@ Plain repository pushes are separate from catalog publication. `Preview Push`
 shows the selected repository push commands. `Push Selected` requires `PUSH` in
 the repository push confirmation field.
 
+The source release panel closes the former gap between a release plan and a
+catalog candidate. `Preview Tag + Publish` is non-mutating. `Create Tags`
+requires `TAG`; `Publish Tags` requires `PUBLISH` and atomically pushes the
+selected branch and annotated tag. The gate requires an aligned target version,
+a clean named branch with a HEAD, and a checkout that is not behind. Existing
+local or remote tags must resolve to the selected HEAD and are never moved.
+The local and remote annotated tag objects must also be identical, not merely
+point at the same commit.
+
 The catalog workflow panel can also operate on the same selected rows:
 
 - `Generate` creates a signed candidate below `runtime/release-candidates/`.
 - `Preview` validates a candidate and shows what would be copied into the
   website repository.
-- `Apply + Tag` requires `APPLY` in the confirmation field.
-- `Push` requires `PUSH` in the confirmation field.
+- `Apply + Website Tag` requires `APPLY` in the confirmation field.
+- `Push Website Release` requires `PUSH` in the confirmation field.
+
+Source release tags belong to Core or module repositories. Website catalog
+publication creates a separate catalog tag in the website repository; the UI
+names these independently to avoid confusing the two immutable references.
+
+Candidate signing is fail-closed: every Core and module source ref in the
+complete post-update catalog must already have the requested annotated tag both
+locally and on the configured source remote. Both tags must be the same
+annotation object with version-aligned tagged package metadata. Selected tags
+must additionally resolve to the selected clean, version-aligned HEAD, and the
+signed `selected_units` record captures the peeled commit and tag-object
+identifiers. Create and publish the source tags before using `Generate`.
+
+Catalog publication repeats that check for selected units and also verifies
+every Core and module source ref in the complete candidate, including entries
+preserved from the previous catalog. Historical refs need not be at the current
+worktree HEAD, but their local and remote annotated tags must match and their
+tagged installable package and module-manifest metadata must declare the catalog
+version. New selected releases additionally pass the stricter current-source
+alignment gate, including public runtime version declarations. A candidate
+cannot be applied or published while any referenced source tag is absent or
+inconsistent; the preview and API response list each repository and missing or
+invalid ref so the operator can repair the exact source releases first.
+
+Read-only provenance checks derive a same-host HTTPS Git URL from conventional
+SSH remotes when possible, with a non-interactive check of the configured remote
+as fallback. Source tag creation and atomic publication always use the explicit
+configured Git remote.
 
 The default signing key is
 `$HOME/.config/govoplan/release-keys/release-key-1.pem` when no signing key is