report does not resolve bare recipe names, unlike every other command

[dubadub]

Every command that takes a recipe resolves bare names through cooklang-find — except cook report, which reads the argument as a literal path.

Reproduction

printf 'Boil @water{1%%l}.\n' > pancakes.cook
printf '{{ ingredients | length }}\n' > t.jinja

cook recipe pancakes
#  pancakes
#  ...renders fine

cook report -t t.jinja pancakes
# Error: Failed to read recipe file: pancakes

cook report -t t.jinja pancakes.cook works, so the difference is purely name resolution.

Cause

src/report.rs reads the recipe with a plain fs::read_to_string, rather than going through cooklang_find::get_recipe like recipe, shopping-list, doctor and the rest.

Why this looks like an oversight rather than a decision

• No comment, doc or help text claims path-only resolution, and the RECIPE argument is described the same way as in other commands.
• report is the only command that reads a recipe this way.
• report's own --base-path flag has no effect on the recipe argument — it resolves against the process working directory regardless — which is an inconsistency nobody appears to have chosen.

Impact

cook report cannot be used with the recipe-name shorthand that works everywhere else, and --base-path does not do what its presence implies for the recipe argument.

Notes

Noticed while extracting report into a library crate. The library side resolves RecipeSource::Path through cooklang-find like every other command, so the CLI is a one-line change away from consistency — it currently passes RecipeSource::Content after reading the file itself, deliberately, to avoid changing behaviour during a refactor. A test on that branch pins the current behaviour so the change has to be made on purpose.