Consider publishing to crates.io for cargo install coop

coop currently installs via install.sh + release tarballs (with build-provenance attestation). Consider also publishing to crates.io so users can cargo install coop.

Considerations:

• Publish under the trailofbits crates.io org/owner (per ToB packaging convention: make trailofbits an owner).
• Cargo.toml would need the usual publish metadata: repository, homepage, readme, keywords, categories (already has description and license).
• src/lib.rs exists only so tests/fuzz can import internals and is explicitly not a curated public API — decide whether publishing an app crate with an incidental lib target is acceptable, or restrict to the binary.
• Wire a cargo publish step into the existing tag-driven release workflow (.github/workflows/release.yml) so it stays in sync with GitHub releases.
• Cross-platform note: cargo install builds from source on the user's machine, so the Firecracker/Lima backend selection and any build.rs/cross-compilation assumptions must work in a plain cargo install build.

This is optional (the checklist only calls for a package-manager account "when packaging"); tarball + install.sh already covers distribution.

Context: identified during the open-sourcing readiness review as a judgment call, now tracked per request.

Start by reviewing Cargo.toml, src/lib.rs, and .github/workflows/release.yml, then check whether a plain cargo install build supports the documented Firecracker/Lima backend selection and cross-platform assumptions. Done means the crates.io packaging decision is resolved, including the incidental library target, and any accepted publication path is synchronized with the tag-driven release process.