Unlink on Settings › Account (open-platform.sh login, parent forge) goes through the confirm page, which says how to link again #7964

Intent: on the web, unlinking a way in asks first, as #7950 makes the terminal do. Linking again is a round trip through another site, so one stray click should not undo it.

Today src/web/pages/account.ts draws both Unlink buttons (edgeLinkView → /settings/edge/unlink, parentLinkView → /settings/parent/unlink) as plain POST forms.

Done looks like:

• [ ] Both are confirmAction({ action, verb: "Unlink" }) from src/web/ui.ts.
• [ ] DESTRUCTIVE in src/web/pages/search.ts gets two entries, added directly after the egress revoke entry (two other issues add entries after the labels entry and at the end): ^/settings/edge/unlink$ with title "Unlink your open-platform.sh login?" and detail "You can no longer sign in here through open-platform.sh until you sign in that way and link it again on this page."; ^/settings/parent/unlink$ with title "Unlink the parent forge?" and detail "You can no longer sign in here through the parent forge until you link it again on this page. The last way in is never removed." Verb "Unlink", phrase "".
• [ ] GET /-/confirm?to=/settings/edge/unlink and …/parent/unlink answer 200 with those titles for a signed-in person; the POST handlers, their same-origin check and the LAST_WAY_IN refusal are unchanged.
• [ ] A test proves each Unlink links to /-/confirm?to=… and the confirm page words it; it fails without the change.
• [ ] bun test on the touched tests passes; bun scripts/design-lint.ts is clean.

Files: src/web/pages/account.ts, src/web/pages/search.ts, test/account-unlink-confirm.test.ts Risks: src/web/pages/search.ts is also edited by #7962 and #7963; each adds its entries at a different place in the list. Brief: a builder who knows the web pages.