A writer seals or unseals an issue from the terminal's issue screen with `S`, after a confirm, in the issue page's words #7996

Intent: a security report can be sealed the moment it is read, from wherever it is read; today only the issue page's Seal form (src/web/pages/issues.ts, through setIssueSealed in src/actions/issues.ts) does it, and the terminal's issue screen (src/tui/screens/issue.ts) shows a sealed report but cannot seal one.

Done looks like:

• [ ] The two sentences the page flashes ("Sealed: only people who can write here and the crew see it now." / "Unsealed: everyone who can read this repository sees it now.") and its two refusals (the mirror one and "Only someone who can write here seals or unseals.") live in one new module, src/actions/seal_issue_words.ts; src/web/pages/issues.ts imports them and types no copy, and the page says exactly what it says today.
• [ ] On the issue screen a writer sees S seal on an unsealed issue and S unseal on a sealed one; a reader does not.
• [ ] S pushes confirmScreen (from ./common.ts): seal reads "Seal #N? Only people who can write here and the crew will see it."; unseal reads "Unseal #N? Everyone who can read <owner>/<name> sees it and its fix." Cancel is selected first.
• [ ] Choosing it calls setIssueSealed(f.app, f.user, repo, issue, sealed) and toasts the module's sentence or refusal; the screen shows the new state.
• [ ] A new test/tui-issue-seal.test.ts proves: a writer seals with S then confirm and the issue is sealed; Cancel leaves it; S again unseals; a reader is not offered S; a sealed issue on a mirror toasts the mirror refusal. It fails without the change. test/sealed-issues.test.ts still passes unchanged.

Files: src/actions/seal_issue_words.ts, src/web/pages/issues.ts, src/tui/screens/issue.ts, test/tui-issue-seal.test.ts Risks: issue.ts is long and other terminal issues touch it; keep the edit to one binding and one key branch. s is taken on that screen, so the key is capital S. Brief: a builder who knows the terminal screens.