Expose rtk as a library crate

Summary

RTK's filtering engine and command classifier are valuable beyond CLI proxy use.

Several modules (filter.rs, discover/registry.rs, utils.rs) already have clean public APIs that return values; they just can't be consumed externally because there's no [lib] target and all modules are private.
i.e. they use mod not pub mod.

Proposal:

• Add a [lib] target to Cargo.toml
• Create src/lib.rs with curated public re-exports.

This will allow downstream crates to depend on rtk as a library (git dependency).

Motivation

Consuming rtk as a library enables:

• In-process output filtering: no subprocess overhead, call filter.filter(content, lang) directly
• Embedding in other tools: LLM agent frameworks, coding tools, etc. without complexity of downloading rtk.

Current State (Why It Doesn't Work Today)

Proposed Change

Modules ready for public exposure (no refactoring needed)

These already return values and avoid println! / std::process::exit():

• filter: FilterStrategy trait, get_filter(level), Language::from_extension(), smart_truncate()
• discover::registry: classify_command(), rewrite_command()
• discover::rules: static pattern/rule data (PATTERNS, RULES, IGNORED_PREFIXES)
• utils: strip_ansi(), truncate(), format_tokens()

Changes needed

1. Add [lib] section to Cargo.toml (name = "rtk", path = "src/lib.rs")
2. Create src/lib.rs with pub mod for the modules listed above
3. Change mod → pub mod in src/main.rs for those modules
4. Ensure src/discover/mod.rs submodules are pub where needed

The [lib] target coexists with the existing [bin]. cargo build produces both, no breaking change.

Out of scope for this issue

The 57+ *_cmd.rs modules (git.rs, cargo_cmd.rs, etc.) use println! and std::process::exit(). Refactoring those to return String is a separate effort that can be tracked in a follow-up issue.

Alternatives Considered

• Fork with lib support: works but fragments the ecosystem; you don't want forks if you can avoid it.
• Separate rtk-lib crate: splits the codebase; inlining the [lib] target in the existing repo is simpler

Also a fork would require publishing under a different name to crates.io , which is undesireable.

Review Cargo.toml, src/main.rs, src/discover/mod.rs, and the listed modules; begin by tracing the current module declarations and existing public APIs. Add the library target and curated exports, then verify that cargo build produces both targets and that the named modules are consumable by downstream crates.