fix(release): keep semantic-release success hooks valid after publishing

[zoeyrose]

Summary

The Content release workflow publishes an artifact and then fails its GitHub
success hook while resolving historical issue references. This leaves release
automation red after publication and prevents downstream consumers from
reliably discovering a verified catalog release.

Evidence

• Failing run: Semantic Release #32659441357
• Revision: 3ed7c55b8e90fd8139e795dd356d31d35c4d8d1d
• The run reaches Published GitHub release: .../releases/tag/v1.0.0, then
  @semantic-release/github fails in its success step with unresolved
  references #308, #287, and #266.
• Those numbers are not Content issues; they are historical references from
  migrated work, so the plugin attempts to resolve them in the wrong
  repository.
• Downstream evidence: Tools Check #32659944624
  receives HTTP 404 for its pinned Content catalog archive.

Analysis

The release builder itself gets through archive generation and GitHub release
publication. The terminal failure is the plugin's post-publication issue
commenting path, which assumes every #N in generated notes belongs to
atrinik/content. The workflow therefore reports failure even though a release
may already have been created, making release state and downstream lock updates
ambiguous.

Proposed solution

1. Preserve the historical release-note text, but make the success hook safe for
   cross-repository or retired references: use repository-qualified references
   where the source can be corrected, and configure the GitHub plugin to skip
   or tolerate unresolved local issue comments for immutable historical notes.
2. Add a release-note fixture containing an unavailable local issue number and
   assert that semantic-release completes without failing after publication.
3. Add a post-publication verification step that checks the tag, commit, all
   expected archives, and SHA256SUMS; make reruns idempotent when the release
   already exists.
4. Publish a verified catalog release that downstream locks can consume. Do
   not repair the Tools lock by guessing a tag or digest.

Acceptance criteria

• Semantic Release is green for the current history, including the success
  phase.
• The published tag points to the intended main commit and every declared
  archive is downloadable and checksum-valid.
• Release notes retain attribution and useful cross-repository links without
  requiring nonexistent Content issues.
• A clean downstream consumer can pin the exact release coordinates.

Related: content#44.