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

The two Unlink buttons on Settings › Account no longer post straight away. The open-platform.sh login one and the parent forge one are now both confirmAction({ action, verb: "Unlink" }) in src/web/pages/account.ts, so each one opens /-/confirm?to=… first.

• Confirm page wording: DESTRUCTIVE in src/web/pages/search.ts has two new entries, directly after the egress revoke entry. They match ^/settings/edge/unlink$ and ^/settings/parent/unlink$ and use the titles and details the issue gives, with verb "Unlink" and no phrase to type. They are placed there so they don't clash with #7962 and #7963, which also add to this list.
• Unchanged: the POST handlers, their same-origin check and the LAST_WAY_IN refusal.
• New test: test/account-unlink-confirm.test.ts sets up an account linked both ways. It checks that Settings shows each Unlink as a link to the confirm page and no longer as a form posting to the route. It checks that each confirm page answers 200 with its title, its detail and a form that posts to the real route, and that opening the confirm page leaves both links in place. I ran it without the source change and it fails.
• Changed test: in test/parent-link.test.ts, one assertion was looking for the raw unlink form action. It now looks for the confirm link. The test was right for the old page; the page changed on purpose.

Checks:

• bun scripts/gate.ts, bun x tsc --noEmit and bun scripts/design-lint.ts are clean.
• scripts/fast.ts named 984 test files, too many to run here. I ran the 14 that mention /-/confirm, DESTRUCTIVE or the edge/parent settings routes: 235 pass, 0 fail.

To try it, on a preview with an edge token or a parent forge configured: link a way in, open Settings, and press Unlink. You land on the confirm page and the link stays until you confirm there.

🤖 Generated with Claude Code

Closes #7964

The two Unlink buttons on Settings › Account no longer post straight away. The open-platform.sh login one and the parent forge one are now both confirmAction({ action, verb: "Unlink" }) in src/web/pages/account.ts, so each one opens /-/confirm?to=… first.

• Confirm page wording: DESTRUCTIVE in src/web/pages/search.ts has two new entries, directly after the egress revoke entry. They match ^/settings/edge/unlink$ and ^/settings/parent/unlink$ and use the titles and details the issue gives, with verb "Unlink" and no phrase to type. They are placed there so they don't clash with #7962 and #7963, which also add to this list.
• Unchanged: the POST handlers, their same-origin check and the LAST_WAY_IN refusal.
• New test: test/account-unlink-confirm.test.ts sets up an account linked both ways. It checks that Settings shows each Unlink as a link to the confirm page and no longer as a form posting to the route. It checks that each confirm page answers 200 with its title, its detail and a form that posts to the real route, and that opening the confirm page leaves both links in place. I ran it without the source change and it fails.
• Changed test: in test/parent-link.test.ts, one assertion was looking for the raw unlink form action. It now looks for the confirm link. The test was right for the old page; the page changed on purpose.

Checks:

• bun scripts/gate.ts, bun x tsc --noEmit and bun scripts/design-lint.ts are clean.
• scripts/fast.ts named 984 test files, too many to run here. I ran the 14 that mention /-/confirm, DESTRUCTIVE or the edge/parent settings routes: 235 pass, 0 fail.

To try it, on a preview with an edge token or a parent forge configured: link a way in, open Settings, and press Unlink. You land on the confirm page and the link stays until you confirm there.

🤖 Generated with Claude Code