Meters render at sub-cell resolution (k9y4k)

Progress and context meters use the eighth-block ramp for the cell at the fill boundary, so a 16-cell bar shows 129 distinguishable levels instead of 17 — at the same width, because all eight eighth-block glyphs measure exactly one cell.

The old full-block-plus-light-shade pair was not a design choice. Read out of the installed Claude Code binary, that pair is its GHOSTTY ink-bleed FALLBACK; its actual meter uses this ramp. Cyberine was shipping the fallback unconditionally.

The empty track also moved off the muted text tone onto the rule tone — a track is structure, and light-shade is visually noisy beside a solid fill. The trailing label stays a text tone; only the track moved.

npm run selftest:tui-meter-resolution renders the real component and reads the glyphs back out of its element tree, rather than re-implementing the arithmetic and measuring the copy. It asserts the bar measures EXACTLY its declared width at 2000 fill levels across five widths — appending a partial cell without subtracting one from the track grows the bar by a cell at every non-integer fill, inside a component that sits in a status line.

Known Limitations and Deferred Work. Some terminals draw eighth-blocks with a hairline seam between cells; the ramp is used unconditionally rather than behind a capability probe. Claude Code's geometric filled/empty shape pair was deliberately NOT adopted — that is a different look, and this change is about resolution, not restyling.