discover/gain: RTK_DISABLED= after a wrapper the hook rewrites through (nice, timeout, command) is never counted as a bypass #4278

Summary

RTK_DISABLED=1 placed after a wrapper that the hook rewrites through is a real bypass — the hook itself flags it — but neither rtk discover nor rtk gain counts it.

$ rtk rewrite "nice docker ps"                  → nice rtk docker ps
$ rtk rewrite "timeout 30 docker ps"            → timeout 30 rtk docker ps
$ rtk rewrite "command docker ps"               → command rtk docker ps
$ rtk rewrite "nice RTK_DISABLED=1 docker ps"   → [rtk] RTK_DISABLED=1 detected — skipping filter for this command. Remove RTK_DISABLED=1 to restore token savings.

So removing the RTK_DISABLED=1 does recover the savings, and the runtime says so. Analytics disagrees: strip_disabled_prefix (src/discover/registry.rs) only peels an ENV_PREFIX match anchored at ^, so nice RTK_DISABLED=1 docker ps has an empty env prefix and the line lands in TOP UNHANDLED under nice.

Measured on develop (c75f1590) with a generated sweep of 264 lines (17 wrappers × 8 supported commands × both orderings) through the real ClaudeProvider, each scored against rtk rewrite "<line without the RTK_DISABLED= token>": 72 real bypasses are not counted, all of the wrapper-first shape (nice, nice -n5, timeout 30, command, …). The number is identical with #3808 applied.

Direction

The analytics peel should be able to see through any wrapper, and let would_be_covered_without_bypass decide — asked about the line the user typed minus the RTK_DISABLED= assignment, wrapper included. That gate already knows which wrappers the hook rewrites through (built-in ones and the user's hooks.transparent_prefixes), so the peel does not need its own wrapper list; it only has to find the assignment. gain's warning has no such gate (#4277), so it should not take this until it has one.

Related: #3756, #3808.