Remove on a cloud account goes through the confirm page, which names the account and says its sealed token goes with it #7982

Intent: removing a cloud account on the web asks first, as the terminal already does (x in src/tui/screens/cloud.ts asks you to type the name); today src/web/pages/cloud.ts draws "Remove" as a plain POST to /settings/cloud/remove with provider and name in hidden fields.

The confirm page posts to its to path exactly, so the account travels in the query: to=/settings/cloud/remove?provider=<p>&name=<n>.

Done looks like:

• [ ] The button is confirmAction({ action: /settings/cloud/remove?provider=${encodeURIComponent(a.provider)}&name=${encodeURIComponent(a.name)}, verb: "Remove", size: "sm" }).
• [ ] cloudRemove reads provider and name from the form and, when the form has none, from ctx.url.searchParams; the admin gate, readForm(ctx, "admin") and removeAccount are unchanged.
• [ ] DESTRUCTIVE in src/web/pages/search.ts gets one entry for ^/settings/cloud/remove\?provider=([a-z0-9_-]+)&name=([a-z][a-z0-9_]{0,31})$, added directly after the settings/origins entry: verb "Remove account", title "Remove the <provider> account <name>?", detail "Its sealed token is deleted from this forge. Anything that used it stops reaching that provider until you add an account again. Nothing at the provider is touched.", phrase "".
• [ ] A new test/confirm-cloud-remove.test.ts proves: /settings/cloud links Remove to /-/confirm?to=…; the confirm page answers 200 with that title for an admin and 404 for a crafted to with an extra parameter; the POST from the confirm page removes the account. Each fails without the change.
• [ ] bun test test/confirm-cloud-remove.test.ts test/cloud.test.ts passes; bun scripts/design-lint.ts is clean.

Files: src/web/pages/cloud.ts, src/web/pages/search.ts, test/confirm-cloud-remove.test.ts Risks: search.ts is edited by sibling confirm issues, each at a different named entry. The route in src/http/server.ts stays as it is. Brief: a builder who knows the web pages.