Cap confidence when invocations alone carry the verdict - #395

Problem

An invocation proves a tool ran. It never proves the tool failed.

When every signal behind the winning class is an invocation, the classifier has already deferred once — it looked for a rule that witnessed a real error and found none. What it hands back is the name of the tool that happened to be running when the job died: a lead, not a diagnosis. The count-based score sold it as one anyway.

Real case, rails/rails run 29648807728: the job dies on a Ruby SyntaxError in actionpack that aborts bin/rails. No failure class covers that. The only matches in 3k lines are three Bundler invocations — bundle install (which succeeded), bundle exec, bundler — and three matches scored ruby_bundle_failure at 0.89, pointing a maintainer at a Gemfile that is fine.

Fix

A verdict whose signals are all in INVOCATION_ONLY_PATTERNS caps at 0.3. Still printed — one lead beats none — but no longer sold as an answer, and plainly above the 0.15 of a decline.

The guard is on the mechanism, not on Ruby, Bundler, or this log: nothing in it names an ecosystem. A rule that actually watched something fail matches a signal outside the invocation set and never reaches the cap, so legitimate last resorts keep both class and confidence — a bare pytest invocation still answers python_test_failure at 0.53.

No new failure class, no new zoo fixture.

Verification

• ci benchmark examples/ci-triage → 223/223, top-1 = 1.0, unchanged.
• Per-fixture before/after diff over all 223 logs: 0 flips — identical class and identical confidence on every one.
• rails log: ruby_bundle_failure 0.89 → ruby_bundle_failure 0.3, same class, honest number.
• Suite: 1005 passed (Python 3.12), ruff check + format clean.
• Regression guard: the raw rails log under tests/data/realworld/ (not the zoo — the benchmark count stays 223), pinning the confidence band rather than the class.