chore(deps): bump cooklang-import to 0.9.14 and cooklang-sync-client to 0.5.0

[dubadub]

Both pins had drifted behind what is published on crates.io:

crate	was	now
cooklang-import	0.9.3 (resolved 0.9.12)	0.9.14
cooklang-sync-client	0.4.11 (resolved 0.4.12)	0.5.0

The sync client's 0.4 → 0.5 bump compiles with no call-site changes — the API cookcli uses is unchanged.

Verified: cargo test and cargo test --no-default-features (14 suites each), cargo fmt --check, cargo clippy --all-targets -- -D warnings.

Note this does not deduplicate reqwest — both 0.12 and 0.13 remain in the tree. See the discussion on why unifying is riskier than it looks.

[claude]

Review: chore(deps) bump cooklang-import → 0.9.14, cooklang-sync-client → 0.5.0

Small, well-scoped dependency-bump PR. Diff is limited to Cargo.toml/Cargo.lock — no source changes, which is exactly right for this kind of change.

Code quality / correctness

• The cooklang-sync-client bump (0.4.11 → 0.5.0) also updates the version requirement in Cargo.toml, not just the lockfile. That's the correct way to handle a 0.x minor bump, since under Cargo's caret semantics "0.4.11" would never resolve to 0.5.x on its own — good catch, and worth calling out explicitly in the PR description (which it already does).

• I checked the actual call sites cookcli has against both crates:

  • src/import.rs only uses cooklang_import::{text_to_cooklang, url_to_recipe}.
  • src/sync/runner.rs only uses cooklang_sync_client::{SyncContext, run_async}.

  Both surfaces are narrow, which supports the claim that the 0.5.0 bump needed no call-site changes despite being a semver-breaking jump for a 0.x crate.

• Cargo.lock diff touches only the two target packages (version + checksum) — no incidental transitive-dependency churn, so the blast radius really is minimal.

Security

• No secrets/credentials involved. Since this pulls forward two dependencies that had "drifted behind" published crates.io versions, it's worth double-checking (outside this diff) whether either bump includes a security fix — the PR description doesn't say either way, so if either upstream changelog mentions a CVE it'd strengthen the justification. Not a blocker.

Performance

• No runtime-affecting change expected; this is metadata/version-only.

The reqwest duplication note

• Good call flagging that reqwest 0.12 (via cooklang-import/cooklang-sync-client) and 0.13 (via self_update) both remain in the tree post-bump. Confirmed via Cargo.lock: self_update 0.44.0 depends on reqwest 0.13.4, while the other two depend on reqwest 0.12.28. This is pre-existing (not introduced by this PR), and deferring the dedup is reasonable — unifying reqwest majors is a separate, riskier change that shouldn't be bundled into a routine version bump.

Test coverage

• No new tests needed — this is a pure dependency-version change with no behavioral surface. The PR description states cargo test (both with and without default features), cargo fmt --check, and cargo clippy --all-targets -- -D warnings were all run locally, which matches the repo's "Before Creating a PR" checklist in CLAUDE.md. I wasn't able to independently re-run cargo check/cargo test in this review sandbox (network-restricted), but nothing in the diff suggests those results would differ from what's reported.

Overall

LGTM. Minimal, well-justified, and the description does a nice job pre-answering the obvious "why not just dedupe reqwest" question.