perf(ui): stop dumping delegate payloads to the console at startup

[sanity]

Problem

Users reported the UI feeling slow/laggy. I profiled the published UI (web-container 30000369) on a real NATed peer with Playwright, measuring per interaction rather than in aggregate.

The cost is startup. Everything else measured clean:

phase	result
startup	~1.75s main-thread blocking, ~12 long tasks, worst ~270ms; rooms usable at ~1.5-2.4s
idle 30s	0.2% CPU, 0 long tasks, 0 DOM mutations
scroll	0 janky frames of 170, p95 16.7ms
room switch	~0.1-0.7s

Then a census of console output grouped by source site found one line is 98.5% of all bytes River emits during startup:

response_handler.rs  "Successfully deserialized as ChatDelegateResponseMsg: {:?}"

ChatDelegateResponseMsg's Debug prints a ListResponse's keys as decimal byte arrays. On a real account: 39 lines averaging ~401 KB each, 14.93 MB of the 15.15 MB total (1,034 messages).

Approach

Summarise instead of Debug-dumping. describe_delegate_response keeps everything the logs were actually used for — variant, key names, sizes, ok/err — and prints keys as the text they are (outbound_dms, rooms_meta, room:<vk>), falling back to a length for genuinely binary keys. Plus:

• payload logged as {} bytes rather than up to 100 decimal bytes
• DelegateKey logged as a 4-byte fingerprint rather than a 32-byte decimal array, at both sites

No log levels changed. My first instinct was to drop release_max_level_info, and the census is why I didn't: that would delete every field diagnostic to fix what turned out to be four call sites — including the Timeout waiting for delegate response warnings that are worth keeping (see below).

Expected effect — a prediction, not a measurement

An A/B that suppressed the app's console entirely removed ~29% of startup blocking (3371ms → 2405ms, mean of 3 paired runs, the counting shim present in both arms so its cost is controlled).

This change removes ~98.5% of the bytes but only 39 of ~1,034 calls. So:

• if the cost is dominated by bytes and formatting, the gain should be most of that 29%
• if it is dominated by per-call overhead, considerably less

The 39 lines also cost roughly 15.6 MB of String building inside WASM, which no console setting avoids, so I expect the former. I will re-run the census and the A/B after publish and post the actual numbers here rather than leave the prediction standing.

Testing

Five new tests:

• key names present and byte arrays absent in a ListResponse summary
• the summary grows with key-name length, not byte-array length
• values reported as sizes, never contents
• binary (non-UTF-8) keys fall back to a length
• a regression pin that fails if either the Debug dump or the byte-array payload log returns, mutation-verified: restoring {:?} on the response makes it red

Also found while profiling, not fixed here

Startup consistently logs Failed to store signing key in delegate: Timeout waiting for delegate response - using local signing and Skipping EnsureRoomSubscription. Delegate round-trips are timing out during load and the app falls back to local signing. That is correctness-adjacent, not just slow, and is consistent with #425, whose burst is now 78 serial requests (26 legacy generations x 3) and whose localStorage "done" gate cannot persist in the sandboxed gateway iframe (opaque origin), so hosted users may re-arm it on every load.

Interaction-time cost is real but tracked separately and not addressed here: #523 (inline closures defeat MessageGroupComponent memoization), #554 (~200 Ed25519 verifies per render via can_participate()), plus an unconditional ~343 KB RoomData deep clone at the top of every Conversation render and no Intl.DateTimeFormat cache. Those are correctness-adjacent enough to deserve their own review rather than riding along with a logging change.

Corrections to my own earlier numbers

• An initial profiler run reported 6.8s blocking / 75.8% CPU. Wrong — inflated roughly 4x by my own CPU sampler (200µs) plus a document-wide MutationObserver. The ~1.75s figure above is from a clean run.
• An initial "~3.1s room switch" was a fixed settle-sleep in my harness, not app cost.

Profilers: framework:~/river-freeze-monitor/{profile_ui.py,ab_startup.py,log_census.py}.

Refs #569

[AI-assisted - Claude]