AppErrorBoundary: report render crashes through reportError with a refId

[TheGreatAxios]

CL-6632

Owner-reported: adding a provider key during onboarding was seen crashing to the React error boundary ("This screen hit a snag").

What I found

Extensive live repro attempts against a fresh signup did not reproduce the render crash itself:

• Anthropic radio (default) with a fake key, from onboarding — connects (onboarding stores immediately, no live probe — CL-6123) and navigates home cleanly.
• Ollama radio with a real tailscale URL, from onboarding — connects cleanly.
• "Skip for now" from onboarding — lands home cleanly.
• Adding an Anthropic key from Settings → AI providers (which does live-probe) — surfaces "API key is invalid." in the dialog, no crash.

I could not find a render-time hazard in onboarding-page.tsx, onboarding.ts, or the credential-test probe logic that would explain the boundary firing, and could not force a repro. Filing this honestly rather than guessing at a fix for the crash itself.

What I did fix

While reading AppErrorBoundary (apps/web/src/app-error-boundary.tsx), I confirmed the ticket's third ask was a real, standing gap regardless of the specific trigger: componentDidCatch only logged through the bare @corbits/client-log getLogger call — never through reportError (@corbits/error-sink) — so any render crash it does catch in production carries no refId and never reaches the structured error-reporting sink. A person hitting the boundary has nothing to quote back to support.

This PR wires componentDidCatch through reportError, stores the returned refId in state, and shows it under the fallback message the same way the onboarding page's own error states already do (Reference: {refId}).

Testing

• Added a test asserting the boundary's fallback shows a quotable Reference: <refId> string after a caught render error.
• bun test test/app-error-boundary.test.tsx — 3/3 pass.
• WORKBENCH_CHECK_SINCE=origin/main bun run typecheck — clean.
• WORKBENCH_CHECK_SINCE=origin/main bun run lint — clean (pre-existing warnings elsewhere untouched).

Follow-up

The underlying render-crash repro remains open. Worth a repro pass with real browser devtools attached (not just agent-browser's a11y snapshot, which won't show a crash that self-recovers or a race that agent-browser's timing missed) directly against the owner's demo path, or a screen recording from the original report.