fix(console+studio): re-enable live 0x84 pattern preview

[floesche]

Summary

• Restores the SD-card pattern thumbnail preview in arena_console.html (renderSdPreview, fetched via GET_PATTERN_FILE / 0x84), which had been swapped for a metadata-only placeholder as a workaround for a controller bug where a stalled host could wedge the link on a 0x84 transfer.
• Extends arena_studio.html's Console-view pattern picker with the same capability: patByteSource() now falls back to a live 0x84 fetch for any (previously previews only worked for patterns uploaded in the current session, the built-in library, or a loaded course-repo protocol).
• Both are safe now that the root cause is fixed on the firmware side: 0x84 large pattern download truncates ~800 KB (firmware 60s deadline + slow console Web-Serial read) LED-Display_G6_Firmware_Arena#16 made GET_PATTERN_FILE chunked and non-blocking with a bounded stall-recovery timeout.

Test plan

• pixi run test (no JS logic in the shared modules changed, so no new automated coverage. This is UI wiring against existing, unit-tested bridge functions)
• Manual: arena_console.html served via python -m http.server, connected over WebSerial, selected an SD-card pattern uploaded in a prior session: thumbnail renders and animates on hover for multi-frame patterns.
• Manual: arena_studio.html Console view, same scenario: thumbnail renders for a pattern never uploaded this session (previously blank).

Dependency

Requires the controller to be running the fixed GET_PATTERN_FILE handler from reiserlab/LED-Display_G6_Firmware_Arena#16 (chunked, non-blocking, bounded stall recovery).

[mbreiser]

Reviewed and hardware-tested against the fixed firmware (reiserlab/LED-Display_G6_Firmware_Arena#27 head, which merged the #16 fix plus review follow-ups).

Code review: clean. The three subtle paths all check out: sendBulkRead returns a fresh exact-size Uint8Array, so u8.buffer in patByteSource is safe (no offset-view hazard); a firmware refusal (display active / transfer busy) rejects at the header phase with a clean error and lands in the best-effort catch — no bulk-drain entered; p.index is built 1-based (i + 1) matching encodeGetPatternFile; concurrent picker changes serialize through the link's send queue; and patPreviewCache prevents repeat fetches. One nit, non-blocking: renderSdMetaCard in arena_console.html is now dead code (defined at line ~3974, zero callers) — worth deleting when convenient. pixi run test passes (full 19-file JS chain).

Hardware verification (macOS bench, Chrome + WebSerial, console): uploaded a pattern via SD Upload, and the live 0x84 preview rendered end-to-end — 20-frame grating thumbnail in the annular projection, 20f badge, hover animation cycling. The re-enabled feature works, and the firmware side is solid: every deliberately-failed transfer during testing recovered cleanly on the next command (the #16 stall-recovery doing its job — the wedge this feature was originally disabled for is genuinely gone).

However, testing surfaced a pre-existing macOS/Chrome Web Serial reliability problem — not a regression of this PR — silent byte loss during bulk reads, which intermittently breaks both the live previews and the existing SD-table Download button on macOS hosts. Full evidence, upstream Chromium references (WICG/serial#164/#166), and a one-line bufferSize mitigation for arena-link.js (big improvement, not a complete cure) are in #153. Linux hosts are unaffected, consistent with your manual verification.

Given the transport issue is pre-existing and tracked separately, this PR looks mergeable as-is to me — with #153 as the follow-up for macOS reliability (relevant if any course benches run Macs).

🤖 Generated with Claude Code