Kitty graphics: Track placements independently from text cells

[anthonykim1]

Follow-up to #5860 and #6131.

The current Kitty graphics implementation stores displayed image tiles in the same cell-backed ImageStorage used by sixel and IIP. PR #6131 restores HAS_EXTENDED as the authoritative indication that a cell still contains active image data. This is correct for sixel/IIP and prevents stale _extendedAttrs from hiding newly written text, but it also makes the current Kitty implementation use WezTerm-style overwrite behavior: writing text evicts the Kitty tiles in those cells.

Kitty graphics uses independent image placements. A placement with negative z is drawn below text, while the default non-negative z is drawn above text. Writing text into the same cells should not delete the placement. Also, C=1 only disables cursor movement after placement; it is not a layering flag.

Proposed direction

• Store Kitty placements independently from the text grid and from sixel/IIP cell tiles.
• Track each placement image ID, placement ID, source rectangle, destination geometry, offsets, z-index, and buffer anchor.
• Render negative-z placements below text and non-negative-z placements above text without consulting stale _extendedAttrs.
• Keep scrolling, resizing, image retransmission, and placement deletion consistent with the stored placement records.
• Do not restore the stale-cell fallback removed by Restore text overwrite of image tiles #6131.

Acceptance criteria

• a=T and a=p create independent placement records.
• Writing text across a non-negative-z placement does not delete it; the image remains above the new text.
• Writing text across a negative-z placement leaves the placement below the visible text.
• Deleting or replacing a placement removes only the intended placement/image data.
• Integration tests cover text writes over both negative and non-negative z-index placements.

Related KGP work remains tracked separately in #5710 (delete selectors), #5711 (Unicode placeholders), and #5712 (relative placements).

[jerch]

@anthonykim1 I have a few changes to do on the ImageStorage, maybe it is time to consolidate things across the protocols:

1. storing of original image bytes, at least as blob data, needed for:

• image addon serialization #5845
• image addon: proper resizing #5861
• animation support for IIP #6139

2. phase out canvas usage, resort to ImageBitmap, needed for:

• image addon: proper resizing #5861
• animation support for IIP #6139

3. placement storing and tracking, needed for:

• image addon serialization #5845

1.) Is mostly straight forward and opens the door for better eviction handling of long running sessions, as we can retain old images high up in the scrollbuffer much longer by moving them into blob space (which the engines put neatly to SSD if the RAM is under pressure). It is a direct requirement for the animation stuff, as holding the data in typed arrays gets really RAM expensive for animations very early. With blobs we can store raw image bytes almost for "free" (does not account in JS heap).

2.) Is needed for proper and fast resizing, either from protocol directives or fontsize / screen resolution changes. Currently the renderer does a poor job always using CSS pixels, which leads to nasty downscaling artifacts on hi-res displays. The details here are cumbersome, as bitmaps introduce async steps in our currently sync drawing.

3.) The placement story is what would may affect this issue here. I will need at least the following for a proper serialization protocol:

• ID based image loads without showing them directly on screen (kitty has that functionality)
• Ideally images can be registered by IDs in bulk upfront, and a "replacement" sequence in the serialization data does the buffer association. I would at least need the placement line-wise, better would be doing it image-wise though (which is hard to get done right).

[PerBothner]

Can we merge PR #5879 or some other solution to the technical debt where the image addon tries to duplicate and extend BufferLine internals? It is really annoying to have to figure out conflicts due to the addon mucking about with BufferLine internals.