Here's the bug that justifies this whole project.

A BOM came through with an inductor whose package cell read `Φ18 x H25 x P7.5 mm`. The quantity column next to it was empty. My early quantity parser did the "helpful" thing: it scanned the row for a number and grabbed one. It found a number inside that dimension string and treated it as the quantity. One line item silently became thousands of parts. The estimated board cost came out 270× too high — and nothing in the output looked obviously wrong. The number was just… large.

That's the nightmare case: not a crash, not an error, just a plausible-looking wrong answer that someone downstream trusts.

The fix wasn't a smarter number-grabber — it was the opposite. The quantity phase now refuses anything that looks like a dimension or spec: if a cell contains units (`mm`, `mil`, `°`), a `Φ`/`ø` symbol, or a `<number> x <number>` pattern, it is rejected as a quantity, the row is flagged, and the quantity defaults conservatively (to the reference-designator count, or 1) instead of to a fabricated value.

It's now a regression test: feed in `Φ18 x H25 x P7.5 mm`, assert the quantity is NOT a four-digit number. Determinism over cleverness — that's the whole philosophy in one test.