docs+bench: storage_mode selection guidance in user-facing docs + a column-favorable calibrated fixture

[Liam0205]

Context

After PR #155, storage_mode selection criteria exist only in llmdoc (transform-heavy + large N + few structural changes → column; recall/filter/sort or small N → row). Two gaps:

1. User-facing docs

• README / doc/ have no storage_mode selection guidance; downstream users cannot discover when column mode pays off
• Add a short section: what each mode is, the selection criteria, and the benchmark shape behind them (BuildInput ~7x faster on column post-perf: three-engine batch column access API + column-major ColumnFrame hot paths #155; transform-heavy e2e ~37% faster; recall/removals/reorder shapes still favor row)

2. Benchmark guardrail

• All calibrated fixtures are "storage_mode": "row" (correct for their N≈10 production shape), so column-mode gains have no calibrated guardian — a regression in the batch access path would not show up in the fixtures we treat as the performance referee
• Add a transform-heavy, large-N fixture variant (shape like pine-go/benchmarks/bench_storage_ab_test.go transformHeavyConfig: one recall + chained transform_normalize, N=1000+) to fixtures/benchmarks/ and wire it into the nightly cross-runtime benchmark matrix, so column-mode wins are watched over time
• Keep it clearly labeled as a synthetic guardrail, not a production proxy (per benchmark-hygiene: calibrated fixtures remain the sole referee for production decisions)

References

• llmdoc/memory/reflections/column-vs-row-parity-investigation.md (usage criteria)
• llmdoc/guides/benchmark-hygiene.md (fixture representativeness)