💡 Color-encoding modes (16-color / 256-color) derived from terminfo #60

Is your feature request related to a problem?

The renderer only generates 24-bit truecolor. emit_attr (src/clayterm.c:90) always emits \x1b[38;2;R;G;Bm / \x1b[48;2;R;G;Bm, with no way to ask for a narrower encoding. Applying the standard ANSI red emits \x1b[38;2;255;0;0m even when the destination is a 16-color terminal, a CI log, or a pipe that would render \x1b[31m better (or only understands the smaller palette).

Describe the solution you'd like

Derive the output color depth from the terminal's capabilities (terminfo), with an explicit colorMode override. We already accept a compiled terminfo binary on the input side (createInput({ terminfo }), input.ts:448); the renderer can read the same source's color capability (max_colors, plus the truecolor flag) to pick an encoding, and take an override for callers who want to force the color mode:

// derive from terminfo capabilities (default behavior stays truecolor—byte-identical to today)
const term = await createTerm({ width, height, terminfo });
// or force it explicitly
const term = await createTerm({ width, height, colorMode: "16" }); // standard red -> \x1b[31m (bg \x1b[41m)
const term = await createTerm({ width, height, colorMode: "256" }); // standard red -> \x1b[38;5;1m

Describe alternatives you've considered

Rewriting the byte stream in TS (parsing emitted SGR and downsampling 24-bit sequences) is fragile and wasteful—it re-parses what the renderer just produced. The reverse-mapping belongs in emit_attr, where the color is known.

Additional context

Failing test case on nm/repro/color-encoding-modes (test · diff).

The core change likely lives in emit_attr (src/clayterm.c:90). Existing terminfo precedent is input.ts:441-448.