Resend API keys

• Provider documentation resend-cli login rejects a key that does not start with re_; the create-API-key response example is re_ + 8 + _ + 24 (re-checked 2026-09-28: 36 characters, no 0/O/I/l) · observed 2026-09-28 · re_ + 8 alphanumerics + _ + 24 alphanumerics, 36 in all; full_access and sending_access keys share the shape
• Reference 1
• Reference 2
• Reference 3
• Reference 4
• Reference 5
• Reference 6
• Reference 7
• Reference 8
• Reference 9

Arrival evidence (#436, product redact-secret#915; #860 handoff resend.md, READY). T1: the provider CLI enforces the re_ prefix (code and README); the 8/_/24 layout is the docs response example and three distinct provider-authored SDK fixture values, which ruling R5 weighs like a docs example. The alphabet is taken as the alphanumeric superset: the samples are base58-consistent, but three samples show what is present, not what is excluded. re_ is short and ends many identifiers (are_, pre_, score_), so the leading boundary matters; the product adds a mixed-case guard (at least one upper- and one lower-case letter in the body) as false-positive policy. That guard is not a provider fact, so the corpus asserts silence only on word-built identifiers of the same layout, never on a random one-case body. Excluded: re_ + GUID mock keys, the 36-lowercase Go webhook placeholder, placeholders and masks, key object UUIDs, and whsec_ webhook signing secrets (another credential class: a twin, never a control). Graduated to a registry detector at the 1127bf9 re-pin (redact-secret PR #938).