fix(ci): release-plz manages only the API client; deploy every push again

[passcod]

🤖 Supersedes #544, which is now redundant — this rewrites release-plz.toml wholesale.

Why the canopy track never worked

release-plz's release command ignores any package whose Cargo.toml says publish = false, whatever git_only says. Every canopy crate is private, so none was ever tagged and the deploy gated on those tags never fired — which is how bes-canopy-api 1.0.0 reached crates.io while canopy itself was neither tagged nor deployed.

Verified against release-plz 0.3.161, the version CI runs. With the workspace uniformly private and bes-canopy-api excluded, release reports nothing to release; removing publish = false from just two crates in that same tree makes it offer to tag exactly those two. The docs claim publish = false "will continue creating git tags", so this looks like an upstream bug worth reporting.

Making the crates visible is not a config tweak. publish = false is what lets this workspace use bare path dependencies: once a crate is packageable, cargo package verifies its manifest and demands a version on all 32 intra-workspace path deps, and cargo package --workspace then builds nine more crates on every release-PR run. A registry allow-list (publish = ["..."]) fails earlier still — cargo rejects the workspace with --registry is required because not all package.publish settings agree.

What this does instead

The two tracks stop sharing a tool. bes-canopy-api depends on nothing in the workspace, so it becomes a cargo project of its own and release-plz manages that alone, via manifest_path on both jobs. Canopy returns to the model it had before the release pipeline: cd.yml triggers on push to main and tags the image sha-<short>, exactly as it did at 39751dee8^.

This also fixes main, which currently fails the release-PR job on every push: release-plz worktrees the last tag and runs cargo package --allow-dirty --workspace there, and the nine *-v1.0.0 tags point at a tree cargo rejects. Confirmed with those tags present that release-plz update against the split project runs clean and proposes only bes-canopy-api: 1.0.0 -> 1.0.1. No tag deletion or force-push is needed — release-plz never looks at the workspace again.

Consequences handled

Leaving the workspace puts the crate out of reach of every workspace-wide cargo command, so just check-api-crate runs fmt, clippy and its tests over it from a new CI job, wired into Tests pass. Dependabot gets a second cargo entry — without it the one crate with outside consumers would stop getting updates. gen-api and check-generated now keep crates/canopy-api/Cargo.lock in step with the version they stamp. And .gitignore picks up the new project's target/, which the root-anchored /target did not cover.

Gating the deploy again is deliberately not attempted here; card raised separately.