chore(deps): bump cooklang-language-server to 0.2.4

[dubadub]

Picks up cooklang/cooklang-language-server#9, which stops the language server enabling cooklang's bundled_units feature — it only parses and diagnoses, and never used the unit database.

Why this is the interesting one

Before #371, this bump would have silently broken cook recipe.

We were getting bundled_units purely by accident: we never declared it, and it reached us through cargo feature unification because cooklang-language-server depended on cooklang with default features. Take that away — exactly what the upstream fix does — and recipe output changes underneath you:

   "quantity": {
-    "scalable": true,
-    "unit": "cups",
+    "scalable": false,
+    "unit": "c",

No warning, no compile error. Just different output.

Since #371 declares bundled_units on our own cooklang dependency, where it is actually used, this bump is a no-op for behaviour:

• cargo tree -e features -i cooklang — bundled_units still enabled
• cargo test — 13 suites pass, snapshots unchanged (recipe output byte-identical)

That is the whole point of #371, demonstrated.

Crate count

Unchanged at 396. We genuinely want the unit database, so the toml/syn/prettyplease/quote codegen chain stays — the upstream change stops it being forced on consumers who do not want it, which is a win for everyone else depending on the language server, not for us.

Verification (CI toolchain, 1.97)

• cargo clippy --all-targets -- -D warnings — 0 issues
• cargo fmt --check — clean
• cargo test — 13 suites pass

Refs #366

[claude]

Review

Reviewed the diff — this is about as clean as a dependency bump PR gets.

Code quality / correctness

• Diff is exactly what the title promises: cooklang-language-server 0.2.3 → 0.2.4 in Cargo.toml and the matching version/checksum update in Cargo.lock. No other packages moved, so there's no accidental transitive drift.
• I independently verified the PR's central claim: Cargo.toml:73 already declares bundled_units explicitly on the direct cooklang dependency (features = ["aisle", "bundled_units", "pantry", "shopping_list"]), with a comment noting this was done specifically so the feature isn't relying on unification through cooklang-language-server. So the upstream change (language server dropping its own bundled_units requirement) genuinely shouldn't affect cook recipe output here — confirms the "no-op for behaviour" framing in the description.
• Worth calling out for anyone skimming the diff without the PR body: cooklang-language-server sits behind the lsp feature (Cargo.toml:31), but lsp is in the default feature set (Cargo.toml:14), so this dependency is part of the default build, not some optional corner — good that it got this level of scrutiny rather than being rubber-stamped as "just a dev dependency."

Security

• Registry checksum was updated alongside the version bump, as expected for a crates.io-sourced dependency. No source/path deps involved, nothing to indicate supply-chain risk beyond the normal trust-the-registry model this workspace already operates under.

Performance

• None expected; the PR body's cargo tree -e features -i cooklang check (bundled_units still present, crate count unchanged at 396) is a reasonable way to confirm the codegen chain (toml/syn/prettyplease/quote) isn't silently dropped or duplicated.

Test coverage

• No new tests needed for a lockfile/manifest-only change. The PR body reports cargo test (13 suites) with byte-identical snapshots plus clean clippy/fmt — that's good evidence the bump is behavior-neutral, though it's worth noting this relied on local/CI runs rather than anything re-verifiable from the diff alone (standard for dependency bumps).

No blocking issues. LGTM.