fix: disable bundled_units so quantities keep their authored units

[dubadub]

Summary

Disables the cooklang bundled_units feature so quantities are displayed exactly as authored, in the units the recipe author wrote.

bundled_units loads the full unit database into Converter::default(), which:

• silently converted quantities to a "best" unit (5/8 cup → 10 tbsp),
• approximated fractions lossily (1 5/8 → 1 2/3, a ~2.6% error presented as exact),
• made the terminal and web UI disagree on the same recipe (web showed 1.625 c, terminal 1 2/3 c).

Root cause

No dependency leaks the feature anymore — cooklang-reports and cooklang-language-server both declare cooklang with default-features = false. It was enabled solely by our own explicit declaration in Cargo.toml, guarded by a stale comment about past feature unification. The comment now documents why the feature must stay off and how to find a future leak (cargo tree -e features -i cooklang).

Behavior after

With the feature off, Converter::default() falls back to Converter::empty() (no code changes needed):

$ cook recipe units-test.cook   # @milk{1 5/8%cup}, @cocoa{5/8%cup}

Ingredients:
  cocoa      0.625 cup
  milk       1.625 cup

Authored units preserved, exact values, full unit names, and terminal/web UI now agree.

Snapshot changes worth noting

• scalable flips false → true: the old conversion path rebuilt quantities via Quantity::new, which hardcodes scalable: false, silently dropping the parser's scalable flag. The new value is the correct one.
• The scaled-recipe snapshot loses a floating-point error term (err: -6.76e-8) left over from the lossy 3 tsp → 1 tbsp round-trip.

Addresses the silent-conversion and web/terminal-consistency parts of #432. The remaining part (opt-in fraction display, e.g. 1 5/8 cups) stays open there.

Checks

• cargo fmt --check, cargo clippy, and the full test suite pass.

[claude]

Review

Small, well-scoped change with a clear root-cause writeup. A few notes:

Code quality

• Good catch tracking this down to cooklang-reports/cooklang-language-server no longer leaking the feature, and leaving a comment (cargo tree -e features -i cooklang) so a future re-leak is discoverable instead of silently reintroducing lossy conversion. That's exactly the kind of "why" comment that earns its keep.
• No source changes needed, which keeps the risk surface small — this is purely a dependency-feature flip plus regenerated snapshots/lockfile.

Behavior / potential issue worth flagging

• PARSER (src/util/mod.rs:50-53) is a single shared CooklangParser::new(Extensions::empty(), Converter::default()) used by both cook recipe output and cook shopping_list (src/shopping_list.rs:300,307,311) for ingredient aggregation across multiple recipes. With bundled_units off, Converter::default() == Converter::empty(), so it's not just display formatting that changes — shopping-list merging of the same ingredient specified in different-but-compatible units across recipes (e.g. 2 cups in one recipe, 500 ml in another) will no longer be unified, since there's no unit database to convert through. That may be an acceptable tradeoff given the accuracy issues described, but it's a functional behavior change beyond "quantities keep their authored units" in cook recipe, and isn't mentioned in the PR description. Worth confirming this is intended, and maybe worth a manual cook shopping_list check with mixed-unit recipes before merging, since the "Testing Approach" in CLAUDE.md notes there's no automated coverage here.

Test coverage

• Snapshot updates look consistent with the described change (units preserved, scalable: true now correct per the parser's flag instead of being hardcoded false by the old Quantity::new rebuild path, and the stray floating-point error term from the lossy tsp→tbsp round trip is gone). No new test was added to explicitly assert "units are preserved as authored" going forward — given this is the entire point of the PR, a small regression test (even just a snapshot on a fixture with 5/8 cup style quantities) would help prevent silent reintroduction if the feature default ever flips upstream.

Security / performance

• No concerns. Dropping bundled_units actually trims the dependency graph slightly (removes prettyplease/syn/proc-macro2/quote from the lockfile), which is a nice side benefit for build times.

Overall this looks correct and matches the stated goal. The shopping-list aggregation implication is the one thing I'd want explicitly confirmed as intended before merging.