feat: add native filter support for GitButler (but) commands

Summary

Add a rtk but subcommand providing native compression filters for GitButler CLI (but) output, mirroring the existing rtk git / rtk gh integrations.

GitButler is a Git workflow replacement (virtual branches / stacks) that's gaining traction with AI-agent workflows because it eliminates the git checkout dance for parallel features. The CLI (but) exposes its own status / commit / push / pull / log / diff / stage / branch subcommands that currently pass through rtk unchanged (no filter exists, so rtk forwards raw output).

Why this matters

1. AI-agent workflow adoption is the core rtk use case, and GitButler positions itself explicitly as "Git for AI agents" (see https://github.com/rtk-ai/grit for an adjacent rtk-ai product targeting the same space). The populations overlap heavily.

2. but status / but log / but diff produce meaningful output on non-trivial stacks. Example but status from a real session with 3 unstaged files + 1 lane with 4 commits:

╭┄zz [unstaged changes]
┊   sw M _planning/mission_notes.md
┊   tz M _planning/mission_plan.md
┊   yp M deny.toml
┊
┊╭┄ch [chore/cleanup-tree]
┊◐   2f777cd feat(gui): ui polish pass and progress update
┊◐   72a05f4 refactor(integrations): extract require_file and schema_counts helpers
┊◐   68b27e0 ci: add Windows GUI clippy and build checks
┊●   a47052c docs(CLAUDE): document GitButler workflow rules
├╯
┊
┴ 7742f8b [origin/master] 2026-04-10 chore: global quality audit — gitignore…

A compressed version could be:

[unstaged] sw M _planning/mission_notes.md | tz M _planning/mission_plan.md | yp M deny.toml
[chore/cleanup-tree] (4 commits local)
  ◐ 2f777cd feat(gui): ui polish pass and progress update
  ◐ 72a05f4 refactor(integrations): extract require_file and schema_counts helpers
  ◐ 68b27e0 ci: add Windows GUI clippy and build checks
  ● a47052c docs(CLAUDE): document GitButler workflow rules
base: 7742f8b [origin/master]

Roughly 40-50% reduction from dropping the tree-art characters (╭ ┄ ┊ ├ ┴ are semantically redundant for text consumers) and folding the [unstaged changes] block into a single line. On larger workspaces (multiple lanes, many unstaged files) the savings compound.

3. but log on a real stack — one commit per line with [lane-name] prefixes and status markers — same compression opportunities as git log.

4. Consistency for users. Users following rtk's golden rule (Always prefix commands with rtk) currently get no feedback signal that but is not optimized. The rtk gain history shows zero entries for rtk but * because of passthrough, which hides real usage patterns from the discovery flow.

Suggested scope (MVP)

A single subcommand rtk but routing to filters for the following verbs, in rough priority order:

• but status — strip decorative tree-art, inline [unstaged] hunks, cap long file lists with (N more)
• but log — one line per commit, drop tree art, consistent with rtk git log format
• but diff — same optimizations as rtk diff / rtk git diff
• but branch list — tabular, trim inactive metadata
• but push / but pull — pass through warnings/errors only, drop progress

Verbs with terse output (e.g. but commit prints only ✓ Created commit <sha>) can safely remain passthrough.

Implementation notes

• but output is already compact relative to git (GitButler invested in TUI ergonomics), so the per-call win is smaller than rtk git log. The multiplier comes from AI-agent call volume, not single-command verbosity.
• but supports -j, --json on most commands (but status -j, but commit -j, etc.). A JSON-first strategy sidesteps TUI art parsing entirely and produces a stable, schema-aware filter.
• but CLI is v0.x and actively evolving; any implementation should probe but --version and degrade gracefully for unknown versions.

Priority

P3-nice-to-have / enhancement. Not urgent — passthrough works. But the trend is visible: GitButler adoption in agent workflows is accelerating, and getting ahead of it would strengthen rtk's story for the agent-dev segment.

Alternative considered

Users can work around this with rtk proxy but <args> if per-invocation customization is acceptable. That preserves tracking but loses consistency, discoverability, and filter quality — not a replacement for native support.

---

Drafted with Claude Code assistance during an agent session that hit ~30+ but invocations with zero rtk coverage.