Add mrrc CLI binary with cat/convert/validate/stats subcommands

[dchud]

Problem

There is no [[bin]] target in Cargo.toml — mrrc is a library only. A small CLI would be a high-leverage showcase for the Rust core, support simple interactive use by catalogers and data engineers, and demonstrate real-world API ergonomics.

What to do

1. Add a binary target to Cargo.toml (either src/bin/mrrc.rs single-file, or a separate mrrc-cli crate in a new workspace member if we want to keep CLI deps out of the library).
2. Use clap v4 with derive for arg parsing.
3. Subcommands:
   • mrrc cat <file> — print records in human-readable form (line-mode/.mrk style ideally, so this depends on or precedes bead for .mrk support)
   • mrrc convert <input> <output> — convert between formats (autodetect by extension: .mrc, .xml, .json, .mrk, .csv, .ttl for BIBFRAME Turtle)
   • mrrc validate <file> — run all validators (IndicatorValidator, IsbnValidator, RecordStructureValidator, EncodingValidator), emit report to stdout or file
   • mrrc stats <file> — record count, tag-frequency histogram, encoding breakdown, average record size
4. Global flags: --recovery-mode {strict,lenient,permissive}, --output-format {text,json}, --quiet, --verbose.
5. Integration tests using assert_cmd + predicates under tests/cli.rs.
6. Document CLI in docs/cli.md with example invocations.
7. Update README with a CLI section showing the most common use: mrrc convert input.mrc output.xml.

Done when

• mrrc binary builds and installs via cargo install mrrc
• All four subcommands work on the test fixtures
• mrrc --help and each subcommand's --help are self-documenting
• Integration tests cover each subcommand's happy path and at least one error path
• README shows CLI examples
• docs/cli.md with examples for each subcommand
• CHANGELOG entry under next version
• .cargo/check.sh passes (including the binary target)

---

Bead: bd-e24e

[acdha]

If you want some scope creep, the most common thing I end up using this for is searching large MARC files with a utility which is roughly search FIELD[$SUBFIELD] REGEX MARC_FILE and either prints the matching records in text format or saves them to a new file.

[dchud]

Well who doesn't love scope creep?

This issue wasn't high in my list of priorities, but adding search makes perfect sense. Would a csv with offsets be helpful, or are just a simple text file or extraction to a new file sufficient?