Feature: user-defined rewrite rules in config.toml (`[[rules.custom]]`)

Summary

config.toml currently exposes [tracking], [display], [filters], [tee], but no surface for user-defined rewrite patterns. Adding [[rules.custom]] would let users prototype rewrites for their own toolchain (and high-frequency misses surfaced by rtk gain --misses — see #1683) without forking the binary or waiting for upstream PRs.

Proposed shape

[[rules.custom]]
match  = "^my-internal-tool .*"
rewrite = "rtk summary $0"
mode   = "allow"      # allow | ask | passthrough
priority = 100        # lower = checked first; built-ins implicit at 1000

[[rules.custom]]
match  = "^helm get values .*"
rewrite = "rtk summary $0"
mode   = "allow"

Semantics:

• Loaded at rtk startup, merged on top of the built-in registry.
• match is a regex anchored as the user wrote it.
• rewrite supports $0 (full original cmd), $1..$N (regex captures).
• mode maps directly to existing exit codes (0 / 3 / 1).
• Built-in registry always wins on conflict unless priority is explicitly lower.

Use cases

1. Internal/proprietary CLIs that rtk maintainers can't ship rules for (company-internal deploy, infra-cli, etc.).
2. Fast iteration on misses (#1683) — a user finds awk is their #1 unrewritten command and ships a custom rule to wrap it in rtk summary while waiting on a proper rtk awk filter to land.
3. Per-project overrides if a .rtk.toml is added later (out of scope here, but custom rules in user config is the building block).

Security considerations

The big risk: a malicious config could rewrite git push to git push --force or similar. Mitigations:

• No shell metacharacters in rewrite substitution. Captured groups are passed as args, not interpolated into a shell string.
• Never rewrite to a binary the user wouldn't otherwise run. Or: require rewrite to start with rtk (could be a separate strict mode).
• Surface custom rules in rtk config show so users can audit what's loaded.
• Document the threat model clearly — config.toml is already trusted (controls tracking, filters, etc.); custom rules raise the stakes but don't fundamentally change the trust boundary.

Why this matters

Today, registry growth is bottlenecked on rtk-ai/rtk PR throughput. With [[rules.custom]], the long tail of internal tools and per-user weirdness becomes self-serve — and the best community-contributed rules can graduate into the built-in registry over time.

Lower priority than #1682 (registry bug) and #1683 (telemetry); listed for completeness as part of the same workflow improvement set.