Support per-band SIXEL palette redefinition for full-color images

[unxed]

Problem

Windows Terminal supports SIXEL, but does not correctly render a valid
full-color SIXEL stream that redefines palette entries between SIXEL bands.

This technique allows a single SIXEL image to contain far more than 256
colors: the encoder reuses the 256 palette registers for each six-pixel-high
band and redefines them before emitting the next band.

Minimal reproduction

Save this as sixel-repro.py and run it directly in Windows Terminal:

import sys

sys.stdout.buffer.write(
    b"\x1bPq"
    b'"1;1;2;12'
    b"#1;2;100;0;0!2~"
    b"$-"
    b"#1;2;0;0;100!2~"
    b"\x1b\\"
)

The first six-pixel band is red and the second one is blue.

Expected behavior

The upper band remains red and the lower band remains blue.

Actual behavior

The color of the earlier band may change when palette entry #1 is
redefined for the later band.

Technical background

The SIXEL format permits palette redefinition during a DCS sequence.
Implementations that support full-color SIXEL need to resolve the palette
color when pixels are decoded, or otherwise snapshot the RGB value before the
palette entry is changed.

This behavior is supported, for example, by
WezTerm
foot

Windows Terminal currently stores indexed pixels and resolves them against the
current color table when flushing the image, so earlier pixels can be affected
by later palette changes.

This is separate from support for multiple DCS images or layered SIXEL
images. The desired behavior is correct rendering of one DCS sequence.

Related: #20020

[j4james]

Windows Terminal currently stores indexed pixels and resolves them against the current color table when flushing the image, so earlier pixels can be affected by later palette changes.

This behavior is by design, firstly because it's more compatible with the original hardware terminals (as well as xterm, vte, mintty, and others), but also because it allows for palette animation effects like the examples I shared in the original PR (see #17421 (comment)).

If you need more than 256 colors, there are already ways you can do that, as you've seen in #20020, and which we've discussed before in the chafa repo. There's no need for us to break backwards compatibility to achieve that.

[unxed]

Ok, solved by implementing overlapping on my side.

[j4james]

unxed I'm happy to see you supporting the layered technique, but I just have a question about your comment here:
https://github.com/unxed/vtui/blob/40ca9cde2e45cd2f8dbfabe36d295d49d6008d98/graphics_sixel.go#L255-L260

// The check is deliberately a single terminal rather than a table. Every
// other terminal vtui sends sixel to takes the full-colour stream, which is
// smaller and needs no compositing promise at all.

What other terminals (besides wezterm and foot) have you actually tested your "full-colour stream" with? Like have you tried any of the ones I mentioned above? Because there are quite a few that I would expect to fail if you're using per-band palette redefinition. At the very least you can be sure that OpenConsole works the same way as Windows Terminal, because that is literally the same code.