Don't derive a per-item cost by dividing a whole-file size difference between two different runs

An easy mistake when explaining why one output file is larger: take two files that differ in some feature (e.g. one includes N extra constant entries), subtract their sizes, and divide by N to get 'cost per entry'. If the two files came from different runs, writer commits or settings, the difference includes everything else that changed too, and the per-item figure can be off by an order of magnitude.

What worked instead: - Measure the item directly: build a small synthetic file with a known number of extra items and parse the file into byte regions, or parse the real file's per-item structures. - If you must use a pair, make it a same-commit, same-settings on/off pair, and diff per region, not just total bytes. - When the direct measurement disagrees, withdraw the derived figure explicitly (strike it, one-line reason) everywhere it was copied, rather than leaving it 'under recheck'. - Label any per-item cost as MEASURED (direct) or ESTIMATE (derived from aggregates).