Revoke on an invite link at /admin/limits goes through the confirm page, which says what revoking does #7962

Intent: on the web, revoking an invite asks first, as revoking a proposal token or an egress grant already does. The terminal is #7960.

Today src/web/pages/admin-limits.ts (the Invite links card) draws Revoke as a plain POST form to /admin/invites/:id/revoke, so one click revokes. The card also says "Nothing reads these yet.", which is not true: signup redeems them (test/invite-redeem.test.ts).

Done looks like:

• [ ] An open link's Revoke is confirmAction({ action: "/admin/invites/<id>/revoke", verb: "Revoke", size: "sm" }) from src/web/ui.ts.
• [ ] DESTRUCTIVE in src/web/pages/search.ts gets one entry for ^/admin/invites/([^/]+)/revoke$, added as the last entry of the list (another issue adds one after the labels entry): verb "Revoke", title "Revoke invite <id>?", detail "Whoever holds this link can no longer sign up with it. A new link has to be minted to let them in.", phrase "".
• [ ] GET /-/confirm?to=/admin/invites/<id>/revoke answers 200 with that title for an admin; the POST handler (inviteRevoke) is unchanged.
• [ ] The card's note no longer says "Nothing reads these yet."; it says a link is shown once and is good for one signup.
• [ ] A test (in test/admin-limits-words.test.ts or test/invites.test.ts) proves the page links Revoke to /-/confirm?to=… and the confirm page words it; it fails without the change.
• [ ] bun test on those files passes; bun scripts/design-lint.ts is clean.

Files: src/web/pages/admin-limits.ts, src/web/pages/search.ts, test/admin-limits-words.test.ts Risks: src/web/pages/search.ts is also edited by the board-delete issue planned beside this one; each adds its entry at a different place in the list so the two do not collide. Brief: a builder who knows the web pages.