feat: sectional onboarding tester for first-request page

[lhagenWP]

Summary

Trial users who just received their API key need to see the API against their own use case, not someone else's. The current onboarding flow on /docs/documentation/making-your-first-request only offered a single hardcoded query (name=John Smith&city=Seattle&state_code=WA), so the first impression every trial user got was a query about someone they have no interest in.

This PR replaces the single-shot <ApiKeyTester /> with a three-section <OnboardingTester /> covering the three primary use cases.

What changes for trial users

Paste API key once, then pick the use case that matches what they're building:

Section	Inputs	Hits	Guide link
Search for a Person	name (req), city, state_code, street	/v2/person	/documentation/person-search
Look Up a Phone Number	phone (req)	/v2/person	/documentation/person-search/reverse-phone-lookup
Search for a Property	street (req), city, state_code (req)	/v2/property	/documentation/property-search

4xx responses get human-readable classification instead of a generic failure — 403 → "invalid key", 429 → "rate limit", 404 → "no results found, your key is working".

Analytics

The legacy single-shot test event is replaced by three section-aware events so engagement can be measured per use case:

• Send (on click): section and the outgoing query params (API key excluded) so we can see what people are actually searching for.
• Result (on response): section, success, status, result_count (sniffed from the v2 response shape — metadata.result_count for person, presence of result for property), and an error tag for 4xx/network failures. The result_count field lets us identify trial users making queries that return nothing.
• Guide click: section, on a guide-link click.

The page-view event already fires on navigation, so a separate per-section impression event isn't needed.

Architecture

• New: src/components/activation/onboarding-tester.tsx (replaces api-key-tester.tsx).
• Proxy at /docs/api/test-proxy becomes a dynamic route under /[endpoint] with an allowlist (person, property) — so the property section can hit /v2/property while the person/phone sections continue to hit /v2/person. The proxy is otherwise unchanged.
• mdx-components.tsx swaps the registration; making-your-first-request.mdx swaps the component invocation and refreshes the intro copy.

Bonus: walkthrough completion-link fix

While reviewing link patterns I noticed src/components/webhooks/walkthrough.tsx hard-coded /docs/... hrefs on its three Link completion links. Next.js's next/link auto-applies basePath, so those hrefs were rendering as /docs/docs/documentation/... and 404'ing. Folded into a separate commit (fix: drop /docs prefix from walkthrough completion links). Reachable only after completing the walkthrough flow at /docs/documentation/webhooks/quickstart, which is presumably why it hadn't been noticed.

Verification

• bun run types:check — clean (only pre-existing bun:test import error, present on main)
• bun run lint — clean
• bun run format:check — clean
• bun run dev — eyeballed all four anchor destinations resolve correctly to /docs/documentation/...