Fix queue release verification outside a checkout

[Shooksie]

The v0.2.0 release published all six assets, but its post-publish check failed because the publish job has no checkout and gh release download could not infer a repository.

Fixes:

• pass the explicit GitHub repository to release view and release download
• add a read-only workflow_dispatch verifier for already-published immutable releases
• validate the release tag and all three archive/checksum pairs without deleting or replacing the release

The published v0.2.0 assets were also downloaded independently and all three archive hashes match their bound checksum files.

[animus-launchapp-gitprovider]

VERDICT: CLOSE

1. PR metadata / head branch codex/TASK-1175-release-verifier-fix — exact symptom: the PR claims TASK-1175, but the authoritative task is “Animus daemon: five-slot generation-fenced coding scheduler and durable leases”, targets launchapp-dev/animus-cli.git at main, and requires durable generation-fenced scheduler/lease work; this PR instead changes only .github/workflows/release.yml and .github/workflows/verify-release.yml in launchapp-dev/animus-queue-postgres. This is an incompatible repository/task-generation collision, so the diff cannot satisfy its originating task. REQUIRED CHANGE: close this misattributed PR; if the release-verifier fix is still desired, create or identify a distinct task owned by launchapp-dev/animus-queue-postgres, then reopen the same minimal workflow edits from a branch named for that task rather than TASK-1175. Verify by fetching the replacement task and confirming its git_repo, title/acceptance criteria, and branch task ID all match launchapp-dev/animus-queue-postgres; then run the Verify Existing Release workflow against an existing immutable release and expect the tag/release validation plus all three archive/checksum pairs to pass.

What is good: the actual workflow edits are small and internally coherent—the explicit --repo "${GITHUB_REPOSITORY}" arguments address gh execution without checkout-derived repository context, and the verifier is read-only. The blocker is provenance and task ownership, not unnecessary complexity in those edits.