feat(rows): the operator is not a reading — ✕ for every multiplication

[lroolle]

What

The ledger row was printing two different X's and calling them both x.

× (U+00D7) has always been a cell — the window the pool will not cover.
x was the ASCII letter standing in for multiplication. The folded tail
put them one column apart in the same red:

before   7d ▁▂▮▯▯...×5hx28 0.7x
after    7d ▁▂▮▯▯...×5h✕28 0.7✕

The first mark is a fact about your week; the second is punctuation. Side by
side in the same tint, it read like a font failure.

✕ (U+2715) is now the operator everywhere the product multiplies:

site	before	after
folded 7d future	...▯5hx28	...▯5h✕28
pace suffix	0.7x	0.7✕
budget notice	- 19x5h left	- 19✕5h left
report	(~4.1 x 5h windows unused)	(~4.1 ✕ 5h windows unused)

Cells are the ink; the operator is punctuation, and it is deliberately the
lighter of the two marks.

Why this codepoint

Row 2 right-anchors the week row to line 1's edge by counting characters
(${#week_plain}), so a glyph that counts one and draws two overhangs the
edge once per pace suffix — the same constraint that keeps ≡ and ☠ on
their single column.

candidate	width	emoji	verdict
✕ U+2715	eaw=N	no	chosen
╳ U+2573	eaw=A	no	doubles under a CJK locale
✖ U+2716	eaw=N	yes	can fall through to a colour font

Both alternatives look stronger and are one MULT_GLYPH=╳ away if a terminal
disagrees. Verified the swap costs exactly what the old ASCII x cost, so the
anchor math is untouched.

Test

418 bats tests (417 + 1 new pinning the glyph at one column, distinct from the
dry cell, and overridable). shellcheck -S error clean. Test-count claims
updated across README, llms.txt, and the Pages demo.

🤖 Generated with Claude Code