chore(deps): dedupe cooklang-find and drop uniffi

[dubadub]

The last link in the dependency chain for #366. Both upstream releases are now on crates.io, so this is unblocked.

What was wrong

cooklang-reports 0.2.2 pinned cooklang-find 0.5, while cookcli depends on 0.6 directly — so we compiled cooklang-find twice. Fittingly, cooklang_find is the crate named in the original build failure in #366.

Worse, both lines pulled in uniffi unconditionally. It exists to generate the iOS/Android bindings and is pure dead weight for a CLI, but it dragged in a whole bindgen chain: uniffi_bindgen, goblin, weedle2, cargo_metadata, scroll, bincode, basic-toml, fs-err.

The chain

1. feat: make uniffi optional behind the ffi feature cooklang-find#8 → uniffi behind an optional ffi feature (published as 0.6.1, default = ["ffi"] so the mobile bindings are unaffected)
2. chore(deps): move to cooklang-find 0.6 cooklang-reports#8 + Hardcoded cover image path #9 → onto cooklang-find 0.6 with default-features = false (published as 0.5.1)
3. this PR → bump to cooklang-reports 0.5.1 and opt out of ffi on our own cooklang-find dependency

Result

$ cargo tree -e normal,build -i uniffi
error: package ID specification `uniffi` did not match any packages

Single cooklang-find 0.6.1 in the graph.

	crates (aarch64)
default	412 → 396
--no-default-features	225 → 201

On the 0.2.2 → 0.5.1 jump

Three majors, but a non-event in practice: we use exactly two symbols, config::Config and render_template_with_config, and both signatures are unchanged.

Verification (against the CI toolchain, 1.97)

• cargo clippy --all-targets -- -D warnings — 0 issues
• cargo fmt --check — clean
• cargo test — 13 suites pass, snapshots unchanged
• Lockfile regenerated from crates.io, no path overrides

Refs #366

[claude]

Review of #372 (chore(deps): dedupe cooklang-find and drop uniffi)

The diff only touches Cargo.toml and Cargo.lock — no source files changed. Summary of what I verified in the lockfile:

What this actually does (confirmed):

• cooklang-find requirement bumped "0.6" → "0.6.1" with default-features = false added. Before, the lockfile carried two cooklang-find entries (0.5.0 and 0.6.0) — a genuine duplicate caused by divergent semver ranges from different dependents. After the bump, both consumers (cookcli, cooklang-reports) resolve to a single cooklang-find 0.6.1. Matches the "dedupe" half of the title.
• Disabling default features on cooklang-find drops its uniffi dependency, which in turn removes the whole uniffi toolchain from the lock: uniffi, uniffi_bindgen, uniffi_build, uniffi_checksum_derive, uniffi_core, uniffi_macros, uniffi_meta, uniffi_testing, uniffi_udl, plus their own transitive deps (bincode, goblin, scroll/scroll_derive, plain, id-arena, iri-string, leb128fmt, cargo_metadata, cargo-platform, static_assertions, fs-err, paste). Since cookcli is a CLI binary with no use for uniffi's FFI bindings, this is a clean, low-risk win for build time and dependency surface. Matches the "drop uniffi" half.
• cooklang-reports bumped 0.2.2 → 0.5.1. That's a big jump for a pre-1.0 crate (where Cargo/semver treats minor bumps as potentially breaking), but since no .rs files needed to change, the API surface used here is apparently unaffected.

Feedback:

1. Scope of the Cargo.lock diff. Only two direct dependencies changed in Cargo.toml, but the lockfile diff touches several dozen unrelated crates (anyhow, tokio, rustls, axum, tower-http, rand, sha2, regex, etc.). That suggests a full cargo update was run rather than a scoped one. For a PR framed as "dedupe X / drop Y," a narrower cargo update -p cooklang-find -p cooklang-reports would make the diff much easier to review and would isolate risk to the two crates actually being touched. If the broader refresh was intentional, it'd help to say so explicitly in the PR description so reviewers aren't left guessing whether e.g. the rustls 0.23.37 → 0.23.42 or tokio 1.51 → 1.52.3 bumps are in-scope or just along for the ride.

2. New duplicate crypto crate versions. As a side effect of the broader update, the lock now carries two live versions of several crypto primitives that didn't exist before: digest (0.10.7 and 0.11.3), crypto-common (0.1.7 and 0.2.2), block-buffer (0.10.4 and 0.12.1), cpufeatures (0.2.17 and 0.3.0), const-oid (0.9.6 and 0.10.2), sha2 (0.10.9 and 0.11.0) — this comes from the getrandom/rand chain pulling in newer majors while ed25519-dalek/cooklang-sync-client still pin the older ones. Not a bug, but a little ironic in a PR whose stated goal is deduping, and it adds lockfile bloat that a scoped update (point 1) would have avoided.

3. Test coverage / verification. Per CLAUDE.md this repo has no automated test suite to speak of, so the main safety net here is CI compiling successfully. Given the cooklang-reports jump spans several minor versions, it'd be worth a manual smoke test of cook report and recipe discovery (cook search, directory listing) before merging, since those paths exercise cooklang-find/cooklang-reports most directly. At review time the Test and claude-review checks were still in progress — worth confirming they're green before merge.

4. Style nit (non-blocking): the default-features = false treatment on cooklang-find is consistent with how cooklang is already declared a few lines above (with an explanatory comment about feature unification). Good consistency.

Security: No concerns — this change only reduces dependency surface (dropping uniffi and its transitive deps). No secrets or credentials involved.

Overall this is a sound, well-targeted dependency cleanup. My main suggestion is to consider re-running cargo update scoped to just the two changed dependencies so the lockfile diff matches the PR's stated intent, or otherwise calling out that a broader refresh was folded in.