Release the route walk and the optional zstd feature so downstream can drop its path override

[Ivanbeethoven]

Context

mst2-codec is consumed by mega2 as a git dependency
(mst2-codec = { git = "https://github.com/gitmono-dev/mst2-codec" }), and its
CI already publishes on version tags. Two additions currently live only on a
branch and are not in the released history:

• Page::pages_along_route(entries, route) — the MTP2 route walk
  (src/metapage.rs): rebuilds each step from the same partition rule build
  uses, then checks the child page id the parent commits to, so a returned page
  is byte-identical to the one the tree refers to. Needed by the server's
  POST /{snapshot_id}/metadata/pages (spec 04 §8).
• The optional zstd feature — src/zstd1.rs plus encode_zstd on the three
  compressible payloads and strict decoding in parse_frame (spec 06): exactly
  one standard frame, window <= 8 MiB, output exactly raw_len, and no
  concatenated / skippable / trailing bytes.

Downstream therefore has to pin a branch or a local path, which is why the
consumer keeps a path override today.

Scope

1. Review and merge the two additions onto main.
2. Decide and document the release channel: tag a version (the CI publishes on
   tags) and/or publish to crates.io, and state which one consumers should use.
3. Document the zstd feature in the README: it is optional, default off, and
   the decoder's strictness guarantees are part of the contract (a lenient
   decode_all-style consumer would accept payloads this codec rejects on
   purpose).
4. Keep the codec pure (no I/O, no async) — the zstd addition must not drag a
   runtime in; confirm the dependency tree stays minimal and note the C toolchain
   requirement (zstd-sys) for builders.
5. State the compatibility rule for the wire format: adding a feature must not
   change any existing encoding, so a consumer without the feature must reject a
   zstd frame rather than mis-decode it (the current behaviour is
   Unsupported).

Acceptance

• cargo test and cargo test --features zstd both pass from a clean checkout.
• A tagged release exists and mega2 can drop its path override and build
  against the released dependency (tracked in the mega2 repository).
• The README documents the feature, the strictness contract and the minimal
  dependency tree.
• cargo clippy --all-targets -- -D warnings and cargo fmt --check are green
  with and without the feature.

References

• Specs 04 §8, 05 §5, 06 (the behaviour the additions implement)
• src/metapage.rs, src/zstd1.rs, src/treeframe.rs, Cargo.toml

[Ivanbeethoven]

Extra facts gathered while filing this (2026-09-17), so the release path is unambiguous:

Nothing is released yet. Cargo.toml still says version = "0.1.0", the repository has no tags and no releases. The only workflow is publish.yml, triggered on v* tags: it checks the tag against Cargo.toml, runs cargo test --locked --all-features, then publishes via crates.io trusted publishing (OIDC).

There is no pull-request or push CI. publish.yml is the only workflow, so a PR has no automated verification — including the one that carries the route walk and the zstd feature. Its green state today comes from manual runs only (locally: cargo test 40 unit + 6 vectors, cargo test --features zstd 53 tests, cargo fmt --check, cargo clippy --all-targets -- -D warnings, and the zstd path exercised end to end by the MST/2 transport oracle decoding frames with the system zstd CLI). Two consequences worth deciding:

1. If the release channel stays git-based, a PR gate (fmt, clippy -D warnings, test with and without --features zstd) is the only thing standing between a bad commit and every consumer tracking the default branch.
2. --all-features at publish time does exercise zstd, but nothing tests the default (identity-only) build in CI, which is the configuration a consumer without the feature gets.

The consumer side is tracked in gitmono-dev/mega2#21: upstream mega2 depends on mst2-codec = { git = "https://github.com/gitmono-dev/mst2-codec" } with no rev or tag, so it tracks the default branch — merging this PR is enough for the consumer to drop its sibling path override; a crates.io release additionally needs a v0.1.1 tag matching Cargo.toml.