Diagnostics: Stop reporting an empty capture as a withheld one

[d4rken]

What changed

When the contribution wizard captures two OEM modes and finds no differences between them, the report it generates now says exactly that, instead of "(no settings approved for inclusion)" — which read as though the contributor had chosen to hide every row.

The report also states what was measured: how many modes were captured, which settings providers were compared, and how many settings actually differed.

Two ways to produce an empty report are now handled:

• A single captured mode can no longer advance to the review step. With nothing to compare against, it could only ever produce a report with no data in it.
• A two-mode capture that finds nothing now shows a card explaining the likely causes — the mode wasn't actually switched between captures, it was switched but captured before the system applied it, or the ROM keeps the setting somewhere Amply can't read — with a "Start over" button. It stays sendable, because the third case is a genuine finding, but the button now reads "Continue anyway".

A capture that manages to read nothing at all is now reported as a failed capture rather than passing silently as a valid result.

Technical Context

Closes the reporting half of #23, where a HyperOS 3 report arrived with an empty matrix and misleading wording.

Why the wording mattered. formatContributionReport emitted one line for two unrelated outcomes: an empty matrix (a measurement result) and an all-withheld matrix (a contributor's privacy choice). The only discriminator was the absence of the optional withheld_rows line — undocumented, and easy to misread as a redaction that never happened. changed_rows now makes it explicit.

Schema 1 → 2. scanned_namespaces, captured_mode_count, and changed_rows are new. Nothing parses these reports (they're read by humans in issues), so there's no migration concern. The new fields are counts and fixed namespace names only — no key or value can reach them, so the privacy path is unchanged: the pure formatter still never sees a raw snapshot.

The single-capture path was the worse bug. deriveMatrix returns rows only where a value set has more than one distinct entry, so one observation yields an empty matrix by construction. goNext() gated on observations.isNotEmpty(), so a one-mode session walked straight through review into a public issue with no data. The ViewModel guard is authoritative (observations.size >= MIN_MODES); the bottom bar mirrors it so the button is visibly disabled rather than inert.

Non-blocking was deliberate. An empty result on an unknown ROM is exactly the signal that its charging mode isn't in the AOSP providers. Blocking delivery would suppress the one case worth hearing about, so the friction is a warning card plus a relabeled action, not a modal.

Capture health. ShizukuSettingsBackend.snapshot() only returns Failure when the binder call throws; a command returning empty or unparsable output parses to an empty map and becomes Success. Three of those merge into an empty snapshot that diffs to "nothing changed" — indistinguishable from the real finding above. The guard triggers only when all three namespaces merge to zero keys, so a legitimately sparse single namespace is unaffected.

Review guidance. ContributionReport.kt carries the discrimination logic; the rest is guards and presentation. The plan and the implementation were both reviewed by Codex; the single-capture gap and the capture-health hole came out of that review.

Testing

• 751 unit tests × both flavors, 0 failures; lintVital{Foss,Gplay}Release and assemble{Foss,Gplay}Debug green.
• New coverage: both empty-case wordings, the new report fields, schema pin, one-capture-cannot-advance, identical-captures-yield-empty-review, restart-from-empty, empty-snapshot-is-a-failure, plus Compose tests for the warning card, the relabeled action, and the disabled/enabled Next states.
• No device run — this touches report text and wizard navigation only, no charge-control path.