fix(playground): wait for browser error reports

[devallibus]

Summary

• add browser sync waiters for screenshot uploads and error reports in the playground DB layer
• make /api/playground/:sessionId/update resolve on actual browser feedback instead of idling on the screenshot timeout
• cover the new wait behavior with timing-aware node tests for failure and success flows

Verification

• bun run test:web
• bun run build:web
• manual local repro with a browser-connected playground session now returns invalid GLSL compile errors in ~96ms instead of waiting ~5s

Closes #71.

Stacked on #72.

[devallibus]

LGTM. The waitForBrowserSyncResult state machine is correct across all scenarios — early break on compilation errors, waiting for both signals on success, and clean timeout handling. The ~96ms vs ~5s improvement is a great UX win.

One actionable item: setErrors is an unused import in $.ts — should be removed. The rest is optional nits (test gaps, clarifying comments).

[devallibus]

setErrors is still imported (line 7) but no longer used directly — the /errors POST handler now goes through recordErrorReport, and no other code path calls it. Should be removed.

[devallibus]

The state machine here is solid — I traced through all five scenarios:

1. Error with messages first → hasCompilationErrors breaks immediately (~96ms path)
2. Empty error first, then screenshot → waits for screenshot after empty error
3. Screenshot first, then empty error → waits for error report after screenshot
4. Both timeout → both flags become false, while loop exits naturally
5. Screenshot first, then error with messages → hasCompilationErrors breaks with both

One thing to note: when breaking early on compilation errors, the screenshot waiter remains registered until the 5s timeout fires. Functionally harmless (promise resolves to null, nobody reads it, waiter cleaned up on timeout). Not worth adding cancellation complexity.

Also: browserResult.errorReport is unused by the API handler — it re-fetches from DB instead. This is correct since recordErrorReport persists before resolving waiters. A brief comment in the API handler could make that intent clearer for future readers, but optional.

[devallibus]

Good coverage of the key scenarios — error-first, screenshot-first, and the interleaved orderings.

Two optional gaps if you want full coverage:

• Timeout scenario: neither event arrives within the window → returns { screenshotBase64: null, errorReport: null }
• structuredErrors only: error report with empty errors but non-empty structuredErrors — the hasCompilationErrors check handles it correctly but there's no test exercising that branch

nit / optional