List Pending Invitations

Invitations this account claimed and can still act on.

Keyed on claimed_by_user_id, never on the caller's email address. That distinction is the whole authorization model: users.email_verified is a single mutable boolean with no record of WHICH address it was proved for (migration 043 backfilled every pre-existing row to true; GitHub sign-in re-points users.email and re-asserts the flag), so "verified, and the string matches" is not proof of control of that mailbox. Listing on the address alone would also turn every undeliverable invitation — bounced, suppressed, or never sent at all because RESEND_API_KEY is unset — from a grant nobody can redeem into one anybody at that address can.

Filtered down to invitations that will actually accept, including the workspace's plan, so the UI never offers a "Join" that 402s. An invitee with nothing here is shown how to get a fresh link, not an error.

NOT behind a feature flag: a flagged-off listing returns [], which is indistinguishable from "you have no invitations" and would silently reproduce the dead end this endpoint exists to remove (CLAUDE.md rule 4).