fix(runtime): align table columns by terminal display width

[samzong]

Table output used text/tabwriter, which counts Unicode code points instead of terminal cells. Mixed ASCII, CJK, and fullwidth values therefore shifted subsequent columns; combining characters could shift them in the opposite direction.

Compute column widths from formatted headers and values with uniseg.StringWidth, then pad each column with spaces. This preserves the existing column selection, labels, value formatting, and two-space gap while handling grapheme clusters. The new dependency has no transitive dependencies. No generated-code or catalog schema change is required; downstream CLIs receive the fix by updating their Lathe dependency and rebuilding.

Closes #174.

Validation:

• make check
• go test -race ./...
• go mod verify
• go test ./pkg/runtime -run '^TestFormatOutput_' -count=1
• The alignment regression fails on the original implementation and passes with the fix, covering ASCII, CJK, fullwidth characters, combining marks, flags, ZWJ emoji, Unicode headers, empty cells, and missing values. A writer-error test verifies error propagation.
• Scratch differential checks confirm byte-identical ASCII table output for representative inputs.
• Regenerated and built the petstore example; petstore __lathe verify --json passed. An HTTP fixture exercised real pets list output and verified aligned Unicode cells and unchanged raw payloads.
• go test ./pkg/runtime -run '^$' -bench 'BenchmarkFormat/table' -benchmem -count=3: the existing 200-row ASCII table benchmark measured 385–400 µs/op before and 372–376 µs/op after, with allocations reduced from 9,466 to 8,447 per operation on Apple M4 Pro. These are local measurements, not a performance guarantee.

[codspeed-hq]

Merging this PR will degrade performance by 22.39%

⚠️ Unknown Walltime execution environment detected

Using the Walltime instrument on standard Hosted Runners will lead to inconsistent data.

For the most accurate results, we recommend using CodSpeed Macro Runners: bare-metal machines fine-tuned for performance measurement consistency.

⚠️ Different runtime environments detected

Some benchmarks with significant performance changes were compared across different runtime environments,
which may affect the accuracy of the results.

Open the report in CodSpeed to investigate

❌ 21 regressed benchmarks

Warning

Please fix the performance issues or acknowledge them on CodSpeed.

Performance Changes

	Benchmark	BASE	HEAD	Efficiency
❌	BenchmarkFormatTableInferredColumns	685 µs	1,089.9 µs	-37.15%
❌	large	1.5 ms	2.1 ms	-31.75%
❌	yaml	3.6 ms	5 ms	-26.56%
❌	BenchmarkParseNormalize	4.3 ms	5.7 ms	-24.47%
❌	small	104 µs	135.2 µs	-23.04%
❌	BenchmarkBuildFlat	1.4 ms	1.9 ms	-22.74%
❌	large	1 ms	1.3 ms	-22.53%
❌	small	99.9 µs	128.8 µs	-22.4%
❌	json-large	2.4 ms	3.1 ms	-22.33%
❌	small	76.2 µs	97.9 µs	-22.16%
❌	json-small	176.5 µs	226.8 µs	-22.15%
❌	large	1.1 ms	1.4 ms	-21.75%
❌	miss	2.7 ms	3.5 ms	-20.81%
❌	BenchmarkCatalogJSON	2.1 ms	2.7 ms	-20.77%
❌	hit	2.7 ms	3.5 ms	-20.73%
❌	table	530.2 µs	657.4 µs	-19.35%
❌	json	974.1 µs	1,198.9 µs	-18.75%
❌	BenchmarkFindCatalogCommand	6.1 µs	7.4 µs	-17.54%
❌	large	1.7 ms	2.1 ms	-17.46%
❌	yaml-large	11.4 ms	13.6 ms	-16.2%
...	...	...	...	...

ℹ️ Only the first 20 benchmarks are displayed. Go to the app to view all benchmarks.

Tip

Investigate this regression by commenting @codspeedbot fix this regression on this PR, or directly use the CodSpeed MCP with your agent.

---

_{Comparing codex/fix-table-display-width (ab832a2) with main (5b10c37)}