How to report privately, and a sealed report opens when its fix is released #892

Stacked on #865. Until #865 lands, review only the last commit. This is the second half of #621. #865 already closes #621, so this pull does not.

• The way in.

- /.well-known/security.txt now says how to report a problem in a repository here privately: open an issue there and tick "Sealed security report" (/<owner>/<name>/issues/new?sealed=1), and you can follow it. - A public repository's page says "Found a security problem? Report it sealed". The link opens the new-issue form with the box already ticked.

• The way out: its fix released (src/actions/sealed.ts, unsealReleased).

- When a pushed tag's commit contains the merge commit of a pull that closed a sealed report, the report and that pull are unsealed, and the change is recorded as issue.unsealed with released: <tag>. - Nothing else unseals automatically: not a branch, and not a tag that does not contain the fix. - The trigger is the post-receive hook.

• Assigned lists (home page, terminal dashboard and /api/v1/user/assigned) never show a sealed report to an assignee who may not see it.
• Terminal: the issue and pull screens' run lists already come through listRepoRuns, which filters sealed reports since #865. No terminal list names runs from elsewhere (nameIssues has no caller).

Tests are in test/sealed-release.test.ts, added to the gate list:

• security.txt mentions sealed reports.
• The repository page links to a sealed report, and the form comes ticked.
• A tag before the fix, and a branch, unseal nothing.
• A tag containing the merged fix unseals the report and its pull, recorded with the tag.
• A sealed report assigned to a reader stays off that reader's list.

The hook's call to unsealReleased is exercised through the function directly, not by a real git push of a tag.

🤖 Generated with Claude Code