gain --failures is noisy for silent successful passthrough commands

Problem statement

rtk gain --failures currently records and displays commands that fell back to raw execution after CLI parsing did not match a dedicated RTK path.

This becomes noisy for commands that are successful by design but usually produce no stdout. A concrete example is:

rtk gofmt <file-or-directory>

gofmt often performs file changes and exits successfully without producing stdout. Today this still ends up in Failures, which makes later inspection harder because the report mixes:

• actual execution failures
• unsupported or unparsed commands that still ran successfully
• silent side-effect commands that are expected to have no stdout

The result is that Failures behaves more like a mixed fallback log than an actionable list of problems.

Why this matters

The current report is useful only if entries are interpretable at a glance.

When successful silent passthrough commands are grouped together with more important cases, the report becomes harder to use for:

• identifying real RTK support gaps
• spotting commands that may deserve dedicated RTK support
• reviewing commands that truly failed or degraded in a meaningful way

This is especially visible because some semantically similar passthrough commands are already handled without showing up as failures, while others go through the global fallback path and do appear there.

Available ways to address the problem

1. Hide fallback entries when the command produced no stdout

This is the most direct idea: if a command succeeded and returned no stdout, do not add it to Failures.

Pros

• immediately reduces noise for tools like gofmt

Cons

• stdout == empty is a weak heuristic
• many unsupported side-effect commands are silent by design, so this would also hide real RTK coverage gaps
• it conflates "no output" with "not worth reporting"

2. Keep recording fallback events, but split or relabel them

Instead of treating all fallback records as "failures", keep the event but distinguish categories such as:

• silent successful passthrough
• successful passthrough with output
• failed execution
• parse or routing mismatches requiring attention

This could be reflected either in storage, in the gain --failures presentation, or both.

Pros

• preserves diagnostic value
• reduces ambiguity in the report
• aligns better with the actual semantics of the tracked events

Cons

• requires a clearer model and likely some naming or UI changes
• slightly more implementation work than a simple suppression rule

3. Fix only a narrow set of known silent tools

Introduce special handling for a small allowlist of commands such as formatters.

Pros

• low-risk and easy to implement

Cons

• arbitrary and hard to scale
• creates command-specific exceptions instead of clarifying the underlying semantics
• likely to keep resurfacing for other silent commands

4. Keep behavior, but rename the report

Another option is to keep the current tracking behavior and change the wording from "Failures" to something closer to the real meaning, for example "Fallback events".

Pros

• cheap change
• more honest naming

Cons

• improves semantics, but does not really solve the noise problem by itself

Recommendation

I recommend option 2: keep fallback tracking, but separate or relabel silent successful passthrough cases instead of hiding them based only on missing stdout.

Rationale

The core issue is not that these commands are silent. The core issue is that Failures currently groups together events with very different meaning.

Using stdout emptiness as the suppression rule is too broad: it would reduce noise, but at the cost of hiding real unsupported-command signals. That would make the report cleaner, but less trustworthy.

A better direction is to preserve the event and improve its classification or presentation so that:

• genuinely actionable cases remain visible
• successful silent passthrough commands stop dominating the report
• RTK support gaps are still discoverable

This keeps the data useful while making the report easier to inspect.

Concrete scenarios to discuss

• rtk gofmt <path> succeeds, changes files, emits no stdout, and currently appears in Failures
• rtk cargo fmt --all is a useful comparison point because it is passthrough-like semantically, but handled through a different path
• an unsupported command that succeeds with visible stdout should still remain discoverable
• a silent command that fails must remain clearly visible as actionable

Open questions

• Should rtk gain --failures remain a fallback log, or become an actionable-problems view?
• Should silent successful passthrough commands be shown in a separate section, or excluded from the default view and exposed via another flag? el also distinguish fallback event types?rting change only, or should the tracking mod