fix: drop path-patched crates from Cargo.lock, gate publish in CI

[BinFlip]

The v0.5.0 publish workflow failed:

error: 1 files in the working directory contain changes that were not yet
committed into git:

    Cargo.lock

Cause

The committed Cargo.lock carried sixteen entries for unrelated sibling crates
— analysir, analyssa, autoit-rs, darwinscope, dotscope, innospect,
mallabel, nimrod, nsis, pascalscript, securs-*, undelphi,
visualbasic. They come from a [patch.crates-io] block in a parent
.cargo/config.toml on the machine the lock was last written on. Cargo strips
them in any checkout without that config, which dirties Cargo.lock, and
cargo publish refuses to run against a dirty tree.

Reproduced in a clean clone of main: cargo metadata alone deletes 64 lines
from Cargo.lock. The v0.4.1 lock had none of these entries, which is why that
release published fine — the pollution was in the working tree when the 0.5.0
branch was cut and went in with it.

Nothing reached crates.io: the publish aborted before upload, so 0.5.0 is
still an available version.

Fix

Cargo.lock regenerated outside that config. No dependency versions change;
only the phantom entries are removed. cargo publish --dry-run now packages
and verifies cleanly.

Adds a Package CI job running cargo publish --dry-run, which performs the
same git-cleanliness and packaging checks as a real publish. Test, clippy, fmt
and doc all passed on the release commit, so nothing existing could have caught
this — the release workflow was the first thing to run publish.

After merge

The v0.5.0 tag and its GitHub release point at the broken commit and need to
be deleted and re-cut from the fixed main for the publish workflow to fire
again.