fix(cli): give both multi-skill discovery modes a report on stdout

[rodrigorjsf]

Closes #114. Closes #115. Closes #116.

Three issues, one user-visible shape reached three different ways: a --format is accepted, a
report is promised, and stdout gets nothing usable. They are one pull request because they touch the
same code and because #115's empty body has to be the empty case of the shape #116 builds — split
across three branches they would have raced each other.

What lands, per issue

#116 — --repo-scan --format json was a concatenation, not a document. It now emits one object:
multi_skill, skill_count, max_risk_score, execution_successful, skills — the same object
--recursive builds, asserted as a key-and-shape equivalence rather than against a literal, so the
two discovery modes answer in one vocabulary. markdown is deliberately left concatenated and
pinned as such; merging Markdown has no shape to reuse and is not this issue's scope. sarif and
terminal are byte-identical to before.

#115 — a discovery miss returned before it built anything. The early return is now a
fall-through, so the requested format is honoured. The exit code stays 0.

#114 — --recursive with no --output wrote no report. -f json and -f terminal now print
the body --output would have received. sarif and markdown stay file-only, which is the brief's
scope; see the deferral note below.

All --recursive claims are qualified once the flag engages — below two immediate child skills it
falls through to an ordinary scan, and test_below_the_threshold_… passes untouched.

The measurement #115 was blocked on: one run, not zero

#115's brief made the option choice conditional on whether a zero-run SARIF log is acceptable to the
consumers this project targets, and required the branch taken to be recorded. Branch 4 was
taken. SARIF 2.1.0 allows runs to be empty ("minItems": 0), but GitHub code scanning documents
"an array of one or more runs" — not acceptable to both — so a discovery miss emits one run
holding no result. This project's own SarifLog.runs_non_empty validator refuses a zero-run log
too, which corroborates the choice rather than having driven it.

That decision has a consequence the issue did not anticipate, and this pull request documents it
rather than hiding it: a one-run-no-result log is byte-indistinguishable from a clean single-skill
scan, so SARIF carries no discovery-miss signal at all. The recipe first shipped here
(jq -e '[.runs[].results[]] | length > 0') was therefore wrong twice over — it fails on a healthy
repository that simply found nothing wrong, and it still cannot see the case it was written for. The
README now says plainly that --format json's skill_count is the machine-readable miss signal and
that SARIF has none.

A defect introduced and then closed inside the same change

_merge_repository_json first derived execution_successful from the exception list. A child that
reports execution_successful: false without raising then exited 2 while the merged body
claimed execution_successful: true / SAFE — measured, not theorised. Both that and
partial-inspection counting are now read off the children. The old concatenated body made no
aggregate claim; #116 created the claim and therefore owed it. The fix is folded into the commit
that created the exposure, not bolted on after it.

#114's stated reason for excluding -f sarif is stale — filed, not silently fixed

The issue argues sarif must wait because --recursive -f sarif --output is a --- path ---
concatenation. Measured on this branch: it is already one merged, validated log. Upstream's
2.9.6 merge replaced the concatenation the issue was written against. Scope was not widened —
sarif stays file-only here — but the false premise was corrected in three contract documents so it
is not repeated, and the measurement is filed as #136.

Review

Three independent critics graded this branch — acceptance-criteria conformance, scope and contract,
adversarial correctness — over two rounds. Every blocking finding is closed on the branch. Four
commits came out of the first round (c90aca0, 0295644, 601e4f2, f21efdd); the last blocking
finding and two README contract errors the critics raised as scope notes were closed in b2b7c14
and 77b0165.

The last blocking finding is worth naming because the behaviour was already right: the guard that
skips the per-skill column heading on a discovery miss had no test. Replacing it with an
unconditional print left the entire unit selection green, because the miss tests assert only that
the warning is present in stderr, and a bare heading beneath it satisfies a containment check.
Proven by mutating that one site — the new assertion goes red, and git diff --exit-code on the
source file is clean after restoring by hand.

Deliberate deferrals

• -f sarif and -f markdown under --recursive with no --output still write nothing to
  stdout. sarif is --recursive -f sarif with no --output still writes nothing, and #114's reason for that is stale #136; markdown has no merged document to print, which is --repo-scan emits parseable output only for --format sarif; json and markdown are concatenated #116's own scope
  boundary.
• Two inline comments still reference --recursive with -f json/sarif/markdown and no --output writes no report at all #114 rather than being deleted as its brief listed. They
  were rewritten as history ("issue --recursive with -f json/sarif/markdown and no --output writes no report at all #114 gave that path the fall-back every other one already had")
  and no longer assert the limitation, which is what the brief was protecting. Recorded as a named
  deviation rather than left silent.
• _combined_json_report returns the caller's skills list by reference, and the <omitted>
  entry is appended after the call, so it lands in the emitted document by aliasing. It matches what
  main already does and was verified on a 34-skill scan (skills_omitted: 2, --output file
  byte-identical to main), but a future defensive list(skills) inside the builder would silently
  drop the omitted entry.
• Two comments refer to --repo-scan finding no skill exits 0 with empty stdout, silently ignoring --format #115 in the present tense as an open complaint, in a pull request that
  closes it. Both are analogies to the problem class rather than claims about current behaviour.

Verification

Run in the main thread on this branch, at 77b0165, after the rebase onto b306027:

make test-unit      4412 passed, 14 skipped, 38 deselected, 4 xfailed
make lint           All checks passed!
make format-check   258 files already formatted
make update-snapshots + git status --short   -> clean, no churn

The Behavior Snapshot gate cannot see any of this — the projection scans through the graph and never
imports the CLI — so a clean snapshot run is evidence that nothing else moved, not that this works.
The evidence that it works is tests/unit/test_cli_streams.py, which asserts result.stdout and
result.stderr apart throughout.