ci: a one-shot bootstrap workflow for termlens-cli's first publish

[vyncint]

termlens-cli shipped in 0.10.0 but is not on crates.io: Trusted Publishing is configured per crate, on a crate that already exists, so the first publish of a new name has nothing to configure it against. release.yml already knows this — it publishes termlens-cli only when crates.io answers 200 and warns otherwise — which leaves exactly one publish that must happen another way. This is that publish, and nothing else.

Safety, since a publish cannot be undone:

• dispatch-only, with a typed confirmation (termlens-cli) so a stray click cannot fire it;
• checks out a tag, not a branch, and re-runs release.yml's tag-matches-version guard;
• --locked, so what goes out is the tested tree rather than whatever the index offers today;
• verified locally first — cargo publish -p termlens-cli --locked --dry-run packaged 9 files and its verify build downloaded termlens v0.10.0 from crates.io, i.e. resolved the dependency the way a consumer will, not through the path.

Not wired to the release environment, deliberately: that environment exists so an OIDC token cannot be minted from a branch, and its policy admits only v* refs. CARGO_REGISTRY_TOKEN is a repository secret, so the environment would add no protection here while blocking the dispatch.

zizmor at pedantic flags use-trusted-publishing on this file. It is right, and this is the one workflow that structurally cannot take the advice — recorded in .github/zizmor.yml with that rationale rather than waved through.

Teardown is in the file's header and I'll do it once the publish lands: link Trusted Publishing for termlens-cli, then revoke the token, delete the secret and delete this workflow. Every release after that goes through release.yml with no stored secret, which is the posture docs/RELEASING.md claims.

Refs #255