Feature: support for `jar tf`, `jar xf`, and `javap` commands

Summary

jar tf, jar xf, and javap are not intercepted by RTK. These commands produce large, verbose output when inspecting JVM class files and JAR archives — common during Android/JVM dependency debugging.

Usage data

From rtk discover on an Android monorepo project (last 30 days):

• 27 invocations of jar xf
• 13 invocations of jar tf
• 11 invocations of javap

Example commands seen:

jar tf /tmp/classes.jar
jar xf /Users/sinan.kozak/.gradle/caches/modules-2/files-2.1/com.bumptech.glide/...
javap -p com/bumptech/glide/integration/compose/ExperimentalGlideComposeApi.class

Why it matters

• jar tf lists every class file in a JAR — large libraries (e.g. Glide, OkHttp) can have thousands of entries
• jar xf extracts files and is often followed by inspecting extracted content
• javap -p dumps full decompiled bytecode including all method signatures

All three produce output that is largely noise for the model — it typically only needs a few specific class names or method signatures, not the full listing.

Expected behavior

• rtk jar tf <jar> — truncate output, show first N entries + summary count ("showing 50 of 3,241 classes")
• rtk javap <args> — truncate to relevant sections, similar to how RTK handles large grep output
• rtk jar xf — passthrough (extraction itself produces no stdout, follow-up reads are handled by rtk read)

Current workaround

Pipe through grep manually: jar tf foo.jar | grep SomeClass — but this requires knowing what to grep for upfront.

Start by locating the CLI interception logic for existing large-output commands and its tests, then trace how command arguments and output truncation are handled. Add handling for jar tf, javap, and passthrough behavior for jar xf; done means listings and bytecode are summarized while extraction emits no proxy output, with tests covering the expected forms.