feat: prefill API key in onboarding tester from ?token= URL param

[lhagenWP]

Summary

When a user arrives at the API onboarding tester with a ?token=<value> query parameter on the URL, decode it and prefill the API Key input. A short note explains where the key came from so the user understands the input wasn't autofilled by a password manager and can edit it if needed.

Users who land on the page without the param see the page exactly as today.

Why token and not key?

The URL value isn't the user's literal API key — it's the URL-safe base64 encoding of it. Naming the param token keeps that distinction obvious so a user (or anyone reading the URL) doesn't confuse the encoded value with the key itself.

Token format

The value is URL-safe base64 with no padding of the key string. This format was chosen because:

• It's natively supported by any standard library (atob after the URL-safe → standard char swap and re-padding).
• It hides the literal key from browser history / referrer headers / server access logs — same data-hygiene reason marketing emails commonly do this for sensitive values.
• It doesn't add cryptographic guarantees beyond what the email-delivery channel already provides: a link recipient could always paste the key manually too.

Decoder behavior (decodeApiKeyFromToken in onboarding-tester.tsx):

• Returns null when the param is absent, malformed, fails to base64-decode, or decodes to something that doesn't look like a printable key.
• Never throws — a bad link cannot break the page.
• When null is returned, the input stays empty and the page renders exactly as it does today.
• A small comment in the source explains the printable-ASCII regex gate (\x21-\x7E) — it's there because atob accepts any valid base64 including binary, and we want to reject decoded results that obviously aren't key strings.

UX

[ API Key ]
[ ******************************************** ]
API key auto-filled from your link — this is your trial key. You can edit
it below if needed. It's shared across all use cases below.

When no key is prefilled, the existing helper text is unchanged:

Your API key is shared across all use cases below.

Hydration

The URL-param read happens in a useEffect, not in useState's initializer, so SSR and the first client render both produce an empty input. The prefill runs on the second client render — no hydration mismatch.

Test plan

• Visit /documentation/making-your-first-request with no query param → input is empty, default helper text shown.
• Visit /documentation/making-your-first-request?token=<urlsafe-base64-of-some-string> → input is prefilled with the decoded value, prefilled helper text shown.
• Visit with ?token=notvalid$$ (malformed) → input stays empty, default helper text shown.
• Visit with ?token= (empty) → input stays empty.
• Visit with ?token=AAAA (decodes to four NUL bytes) → input stays empty (regex gate rejects non-printable).
• Edit the prefilled input → typing works as expected; the prefilled text is replaced character-by-character.