fix: ship docs/ascii_art.txt inside peeroxide-cli + add publish-check CI gate

[eshork]

Why

The release-plz publish workflow for peeroxide-cli 0.2.0 failed with:

error: couldn't read `src/../../docs/ascii_art.txt`: No such file or directory (os error 2)
error: could not compile `peeroxide-cli` (bin "peeroxide") due to 1 previous error
error: failed to verify package tarball

peeroxide-cli/src/main.rs was reaching outside the crate root via include_str!("../../docs/ascii_art.txt"). cargo publish packages only files inside the crate directory, so the asset was absent from the tarball and the verification rebuild couldn't find it.

The bigger problem: cargo build and cargo test both passed against the live workspace tree where the file does exist, so CI happily merged the PR. The breakage only surfaced when release-plz ran the publish-equivalent verification compile against an unpacked tarball — at which point the broken state was already on main.

What

1. Fix the asset location. Move the file to peeroxide-cli/src/ascii_art.txt (using git mv so history is preserved) and update the include path to include_str!("ascii_art.txt"). The asset is now inside the crate root and ships in the published tarball.

The only programmatic consumer of the file was the include_str! in main.rs. The workspace README, peeroxide-cli/README.md, and docs/src/introduction.md all inline the ASCII art as literal text, so no doc/README changes are needed.

2. Add a CI gate that would have caught this. New publish-check job in .github/workflows/ci.yml runs cargo package --workspace on every PR. Empirically verified that this command:

• Packs every workspace member into target/package/ in topological order
• Sets up a tmp-registry at target/package/tmp-registry containing the sibling tarballs
• Runs the verification compile of each crate against that local registry (not crates.io)

So it catches both:

• include_str!/asset paths that escape the crate root — what bit us this time
• Cross-crate API mismatches — without false-positive failures when a PR legitimately needs unpublished sibling API, because the verify step sees the bumped sibling version locally

This is the same verification step release-plz runs at publish time. Running it on every PR catches publish-only failures before merge instead of after.

Verification

• cargo build -p peeroxide-cli — green
• cargo package -p peeroxide-cli (full verify against unpacked tarball, same step that failed in CI) — green
• cargo package --workspace — green; verify steps unpack siblings from local tmp-registry as expected

Notes

• No public API change in any crate.
• No version bumps; the published 0.2.0 / 1.3.0 versions were never actually released to crates.io because the publish step failed — this fix lets release-plz retry cleanly.