Clear pre-existing cargo-audit advisories (zip 0.6, time, bytes, crossbeam-epoch) and fix the stale MSRV declaration #63

Context

Found during the eMudhra CA audit that shipped as 2.4.0 (#62). After that release cargo audit still reports six vulnerabilities, all pre-existing and unrelated to the CA incident, and the crate's rust-version = "1.75" declaration is not true in practice. Both were deliberately left out of #62 to keep that change scoped; this issue tracks cleaning them up in a normal maintenance PR.

1. Open cargo-audit advisories

Notes:

• The three zip advisories are all in extraction (symlink targets outside the destination, SUID/SGID bits preserved, permissions applied through symlinks). That is exactly the path download_binary runs on an archive fetched over the network. The source is trusted, but this is the one place the CLI unpacks remote content, so it deserves defence in depth.
• bytes and crossbeam-epoch are semver-compatible bumps: cargo update -p bytes -p crossbeam-epoch.
• time disappears with the zip upgrade (it is only reachable through zip 0.6).
• zip 0.6 to 9.x is a major upgrade. ZipArchive::extract still exists, but default features pull in many compression backends; we only need deflate, so set default-features = false. It also drops the pbkdf2 / password-hash / base64ct chain, which matters for the MSRV point below. Latest is 9.0.5 with rust-version 1.88.

2. Stale MSRV declaration

Cargo.toml declares rust-version = "1.75" and AGENTS.md repeats it, but:

• Cargo.lock is lockfile format v4, which cargo 1.75 cannot parse (needs 1.78+).
• Compiled crates already declare a higher floor: base64ct 1.7.3 (via zip 0.6) requires 1.81 and fails to compile on 1.75 (error_in_core); litemap 0.7.5 and zerofrom 0.1.6 (via url / idna / icu) declare 1.81.
• Nothing in CI builds with the declared toolchain; every workflow uses dtolnay/rust-toolchain@stable.

Verified in #62: with only base64ct pinned back, the whole crate including the new TLS stack compiles on rustc 1.75.0, so the TLS change itself did not move the floor. The declaration was already wrong.

Proposed resolution:

• Choose the MSRV deliberately after the zip upgrade (the zip 9.x and time 0.3.5x floors suggest 1.88 if taking latest; pinning slightly older releases of those two could hold 1.85). Set rust-version accordingly and update the sentence in AGENTS.md.
• Add a CI job that runs cargo check --locked with dtolnay/rust-toolchain@<msrv> so the declaration is enforced from then on.
• Add .cargo/config.toml with [resolver] incompatible-rust-versions = "fallback" so cargo update stops silently pulling crates above the declared floor (this is what Distrust compromised eMudhra intermediates (reqwest 0.12, webpki-roots 1.0.10), release 2.4.0 #62 used by hand via CARGO_RESOLVER_INCOMPATIBLE_RUST_VERSIONS=fallback).

Acceptance criteria

• cargo audit reports no vulnerabilities (the existing unmaintained-crate warnings are out of scope).
• cargo check --locked passes on the declared rust-version toolchain in CI.
• ci-scripts/lint.sh and ci-scripts/test.sh pass; stackql-deploy upgrade still downloads and extracts the stackql archive on all six release targets (the release workflow's runtime smoke test covers this).
• A unit test for extract_binary with an archive containing a path-traversal or symlink entry, asserting it is rejected, so the extraction behaviour is pinned rather than assumed.
• CHANGELOG.md entry under the next version; AGENTS.md MSRV sentence updated.