feat: unified invite flow — knock any Voltius user (server)

[kipavy]

Server half of the unified invite flow: a host can now find any Voltius user — teammate or not — by @handle or full email address and knock on them, and the recipient joins in one tap or declines.

Pairs with VoltiusApp/voltius#122 (client). This one must land and deploy first: the client degrades safely against an old server (search simply returns fewer rows), but the client half is inert without these endpoints.

What it adds

• A handle namespace (migration 035). Every user gets one at registration and existing users are backfilled, so "copy my address" works for a free account without exposing an email. Pro and above may claim a custom handle, which is what makes them fuzzy-searchable. Handles are never recycled — released ones move to retired_handles permanently, so a remembered @kevin can never become a stranger wearing that name. A reserved list rejects vendor names and their near-variants (voltius-support, adm1n).
• A rewritten /v1/users/search. Teammates match fuzzily on name and email; anyone with a custom handle matches fuzzily on that handle; everyone else resolves only on a full email address or an exact handle. Email-substring matching is deleted — it was an enumeration oracle, and deleting it beats rate-limiting it. public_key is removed from the response; the endpoint gains its own limiter.
• Stranger knocks in grant_invitee, gated on the recipient's opt-out, their block list, and a per-sender budget (STRANGER_KNOCK_RATE_LIMIT, default 20/hour).
• Name redaction: an unaccepted stranger sees no session name, no participant list and no participant count. A mis-aimed invite leaks a handle, never a hostname.
• Decline and un-invite, both clearing all three pieces — durable row, wrapped key, and the in-memory admission set. Decline blocks the sender for 7 days silently, or permanently on request.
• GET /v1/users/:id/public-key, because key material must be read fresh at wrap time and a stranger shares no team roster to read it from.

Two things worth a reviewer's attention

Blocks and opt-outs are indistinguishable from success, by design — a sender must learn nothing. That is why suppression writes no grant, and why suppressed_invites exists: without it the host's own invitee_ids would reveal the outcome by omission. A suppressed knock therefore occupies a guest seat exactly as a real pending invite does; un-invite frees it. A residual timing difference remains (the granted path genuinely writes rows) and is documented rather than padded.

Migration 035's backfill was quadratic and measured 96s at 20k users inside the startup transaction, with ACCESS EXCLUSIVE on users — the server would have been down for the duration. Creating the unique index before the backfill brings it to 4.3s at the same size. Timings were measured, not estimated. The migration has never been released, but any developer database that applied an earlier revision of it must be dropped or sqlx will refuse to start.

Behaviour change on a shipped surface

The Members invite panel calls the same search endpoint, so it gains handle lookups and loses email-substring matching. It is only harder than before when the invitee has no custom handle and the inviter does not know their full email address; anyone on Pro or above who claimed a handle is easier to invite than before.

Verification

236 tests pass against a real Postgres, clippy clean at -D warnings. Verified live in a two-account run against a throwaway stack: the knock arrives with no session name, decline writes nothing on the next knock, un-invite returns 403 to a non-host and 204 to the host with rows and key gone, and the redaction holds on the wire and not merely in SQL.

Known limit

Sock puppets are not solved: accounts are free and blocks are per-user-id. The escalation lever, if abuse appears, is restricting knocks to handle-holders or paid accounts. Knocks are logged to tracing rather than audit_logs, which requires a team_id a stranger knock does not have.