fix: normalize invalid RGB in keyframes

[vitorbaptista]

Summary

• normalize avt's ambiguous colon RGB parameters where keyframes are generated
• cover the spelling in the existing keyframe e2e test

Root cause

avt serializes truecolor as 38:2:R:G:B (parser.rs:961 on main; color.rs:16 in the pinned 0.16). T.416 does not allow that form: the color-space field is positional, not optional, so a reader following the spec takes G and B for R and G and defaults B to 0 - a periodic keyframe repaints an otherwise correct terminal in yellow-green.

avt's own parser accepts the form it emits (its tests parse 38:2:1:2:3 and 38:2::1:2:3 to the same color), so its dumps round-trip cleanly and the damage only appears in a real emulator. It is still present on avt main, so upgrading would not fix it - worth reporting upstream separately.

xterm.js is not the place to fix this. xtermjs/xterm.js#5792 reported exactly this and was closed as working-as-intended, citing T.416 and DEC STD 070: an omitted middle parameter must still be separated, so positions never shift with parameter count. Of the three spellings in the wild, 38;2;R;G;B is non-conformant but universally supported, 38:2::R:G:B is the only strictly correct one, and 38:2:R:G:B - avt's - is simply invalid. The emitter is what has to change.

Approach

The rewrite happens at the one place we generate those bytes. Two facts make it a three-line transform rather than a pattern match:

• screen text can never contain an ESC (avt's parser consumes control chars instead of storing them as cells), so a CSI-bounded scan cannot touch user text;
• the only colons avt puts inside an SGR are colors, so every colon in a ...m run can become a semicolon. 38:5:N folds to 38;5;N, which is equally valid.

Vt::dump() also appends in-flight parser state as a final-byte-less CSI, so the end of the dump terminates a sequence too - otherwise a keyframe that fires mid-SGR ships an un-normalized trailing color.

Params that already spell the empty color space (38:2::R:G:B) pass through untouched, so if avt is fixed upstream to emit the valid colon form, bumping the dependency does not silently re-break the colors by flattening :: into ;;.

Deliberately not fixed in the viewer

An earlier revision of this PR also rewrote SGR in room.js for already-released broadcasters. Dropped after review:

• the viewer cannot distinguish an old broadcaster's keyframe from any application's live output, so it rewrote every session's bytes - contradicting "raw bytes end to end";
• measured ~4.1 ms per 31 KB colored frame, synchronous in onmessage/the decrypt chain (~130 ms block on a 1 MB history replay); the indexOf(0x1b) fast path misses on essentially every TUI frame;
• the bounded carry needed for split CSIs silently gave up past its cap, passing through exactly the ambiguous form it existed to fix;
• and it could not fix the unterminated trailing CSI at all, since its regex needs the closing m.

Trade-off: released binaries in the wild keep emitting the ambiguous form, so their keyframes stay miscolored for late joiners until the user upgrades. Cosmetic, self-healing on upgrade, and not worth a permanent per-frame cost on every viewer.

Testing

• cargo clippy --all-targets clean
• normalizer verified against real avt::Vt dumps: fg/bg RGB normalized, 38:5:196 folded, literal screen text HI 38:2:1:2:3 untouched, unterminated trailing CSI normalized
• normalizer also verified to leave the valid 38:2::R:G:B form byte-for-byte unchanged
• full e2e suite: 259 passed

Fixes #189