Add contextzip yarn and contextzip bun command routing

[osazemeu]

#11 teaches compress_pkg_log the yarn and bun formats, but there is no route that feeds their output into it. src/main.rs has Commands::Npm and Commands::Pnpm; there is no Yarn or Bun, and src/discover/rules.rs has no rewrite_prefixes entry for either, so contextzip rewrite "yarn install" exits 1 and the hook leaves the command alone.

So today the yarn and bun filtering is reachable only if something else calls compress_pkg_log on that output.

What routing would need

Following the shape of src/npm_cmd.rs:

• Commands::Yarn and Commands::Bun in the main.rs Clap enum, with trailing var args
• src/yarn_cmd.rs and src/bun_cmd.rs, each dispatching install-type subcommands to compress_pkg_log and everything else to a passthrough filter, as npm_cmd::run already does for install | i | ci
• CzRule entries in src/discover/rules.rs so the hook rewrites yarn install and bun install
• entries in RUST_HANDLED_COMMANDS in src/toml_filter.rs, so a TOML filter matching the same command warns about being shadowed
• is_operational_command in main.rs for the integrity check
• the command tables in src/init.rs and the README

Worth noting that bun run and yarn <script> need the same "is this a subcommand or a script name" disambiguation npm_cmd.rs already does with NPM_SUBCOMMANDS, and that bun's subcommand set is quite different from npm's.

Splitting yarn and bun into separate PRs would probably keep each reviewable.

Measured savings

From the real fixtures in #11, so a rough idea of what routing would unlock:

command	saved
yarn install (classic 1.22.22)	65%
yarn install (berry 4.18.0)	73%
bun install (1.4.2)	81%

Berry 2 and 3 would do considerably better than the 4.x figure, since they emit per-package cache lines in a sliding window (around 250 lines for 54 packages) where 4.x prints one aggregate line.