fix: HAR captures 0 entries — dangling HashMap keys cause new CDP client per request

[lekt9]

Summary

HAR recorder always returned 0 entries because every HTTP request created a new CDP client instead of reusing the existing one. Network.enable was sent on connection #1, but navigate and harStop used different connections that never received network events.

Root cause

getCdpClient() and getHarRecorder() in bridge.zig stored tab_id slices directly as StringHashMap keys. These slices point into per-request arena memory that is freed after each HTTP handler returns. On the next request, the new tab_id slice has the same content but a different memory address, and since the old key's memory was freed, HashMap.get() reads garbage and never matches — so it creates a new client every time.

Verified with debug logging:

# Before fix:
getCdpClient: creating NEW client for tab ABC...
getCdpClient: creating NEW client for tab ABC...  # different WS connection!
getCdpClient: creating NEW client for tab ABC...  # yet another!

# After fix:
getCdpClient: creating NEW client for tab ABC...
getCdpClient: reusing existing client for tab ABC...  ✓
getCdpClient: reusing existing client for tab ABC...  ✓

Changes

• bridge.zig: Dupe tab_id keys with allocator.dupe() before HashMap.put() in both getCdpClient() and getHarRecorder()
• client.zig: Replace fixed 32-slot EventBuffer with dynamic ArrayListUnmanaged so events aren't silently dropped. Add drainWsEvents() for mutex-safe WS reading.
• router.zig: Use drainWsEvents() instead of direct WS access. Fix flushEventsToHar() to clear buffer without double-freeing arena-allocated events.
• har.zig: Send Network.disable before setting recording=false so late events are still processed.

Results

• httpbin.org: 0 → 2 HAR entries
• nusmods.com: 0 → 19 HAR entries
• No crashes (previously crashed with Invalid free in EventBuffer)

Closes #118, closes #120

[justrach]

The runtime fix looks directionally right, but this patch introduces ownership regressions that should be fixed before merge.

1. flushEventsToHar() now clears client.event_buf without freeing the buffered event payloads. Those payloads can be allocated from the bridge allocator during Network.enable / Network.disable, so this leaks event strings across HAR sessions.
2. The new duplicated tab_id keys inserted into cdp_clients and har_recorders are not freed in Bridge.deinit() or removeTab(), so each tab now leaks one key per map.

I opened #123 with the same cross-request HAR fix, plus the ownership cleanup and validation against the original httpbin.org/get repro.

[justrach]

Closing — the core fixes here are already on main:

• Bridge allocator.dupe(tab_id) for HashMap keys ✅
• Dynamic ArrayListUnmanaged EventBuffer ✅
• drainWsEvents() helper ✅
• HAR entry ownership/cleanup ✅

The remaining response-body capture is handled more cleanly in PR #127, which will be merged separately.