Define a release procedure that gates on the security/e2e suite

[nhuelstng]

Context

Follow-up from #100 (which moved the model-free e2e tests onto the PR path via the e2e_fast tag). That PR deliberately did not touch the release flow — this issue tracks designing one.

Problem

release.yml is triggered on a v* tag and gates goreleaser on a single test job:

- run: go test -race -count=1 -timeout=10m ./...

That runs the untagged build, so it excludes all of internal/e2e/ (everything there is behind //go:build e2e / e2e_fast). Consequences for a release cut:

• The fast security-regression slice (-tags=e2e_fast) — dir_token isolation (fix(serve): stop /__omac__/dirs from leaking other workdirs' tokens #74), the mutation-tested assertion predicates (fix(sandbox,e2e): protect docker.sock, harden fs assertions to per-path #84), the --no-sandbox exposure report (e2e: testing ideas to validate (security + creative) #66), registry invariants — does not run before a tag is published, even though it now runs on every PR.
• The full live suite (e2e.yml) runs only on the Saturday cron / manual dispatch, so a tag cut mid-week ships against a security audit that may be up to a week stale.

Nothing currently ties "this commit passed the security audit" to "this commit is being released."

What to decide

• Minimum gate before goreleaser runs: at least go test -tags=e2e_fast (cheap, model-free). Wire it into release.yml's test job or as a needs: dependency.
• Whether/how to require a recent full live e2e.yml pass for the released SHA (e.g. release only from a SHA the weekly suite already validated, or trigger a live run on the tag — noting the claude-code billing and macOS/codex --no-sandbox caveats).
• Where the release procedure is documented (a RELEASING.md / checklist) so it's reproducible, not tribal knowledge.
• Pre-release vs. final-release policy (e.g. allow -rc tags to skip the live suite but not final tags).

Non-goals

• Re-scoping the backlog in e2e: testing ideas to validate (security + creative) #66 — this is specifically about the release gate, not new probes.

Refs #66, #100