Algorithm-level PARTIAL discharge for FALSIFY-QA-001 (every
registered apr command exits 0 on --help) per
`contracts/apr-cli-qa-v1.yaml`.

## What this binds

`verdict_from_help_subcommand_smoke(commands_tested, commands_passing_help_smoke)`
returns Pass iff:

1. `commands_tested == 58` (canonical apr CLI surface)
2. `commands_passing_help_smoke == commands_tested` (every command's
   --help exited 0)
3. `commands_passing_help_smoke <= commands_tested` (counter sanity)

Pinned constant: `AC_QA_001_EXPECTED_COMMAND_COUNT = 58`.

## Why pin 58 commands explicitly

Per spec §26.8 / CLAUDE.md: the canonical apr CLI surface is 58
subcommands (57 original + `mcp` added in PR #864 on 2026-04-17).
A regression that adds or drops a subcommand without bumping the
contract trips the gate three different ways:
- `tested == 59`: phantom subcommand added (caught by
  `fail_phantom_subcommand_added_57_to_59`)
- `tested == 57`: subcommand dropped (caught by
  `fail_subcommand_dropped`)
- `passing < tested`: dispatch broken (caught by
  `fail_one_command_broken`)

## Why two-counter shape (tested + passing)

A single `passing == 58` check would conflate two distinct
regression classes:
- "Registry has 58 commands and all dispatch" (true Pass)
- "Registry has 60 commands, 58 happen to pass --help, but 2 are
   broken" (silent Pass under single-counter)

Tracking `commands_tested` separately catches the second class.
Section 4's `fail_phantom_subcommand_added_57_to_59` test exercises
exactly this regression shape — 59 commands all pass --help, but
the count drift is the actual defect.

## Five-Whys

1. Why bind QA-001 now? — `apr --help` smoke is the most
   user-facing CLI gate; without a verdict pin, a phantom
   subcommand or broken dispatch ships invisibly until users
   hit "command not found".
2. Why a (u64, u64) pair? — Algorithm-level pin; the actual
   per-subcommand `--help` invocation harness is FULL_DISCHARGE.
3. Why pin 58? — Catches add/drop drift; matches CLAUDE.md
   canonical claim.
4. Why two counters (not one)? — Distinguishes "registry size
   drift" from "dispatch broken" — both must Fail but for
   different reasons.
5. Why 13 tests across 7 sections? — Provenance pin (×1),
   pass band (×1: canonical 58/58), broken-dispatch fail (×3),
   count-drift fail (×3: phantom, dropped, zero), partition
   violations (×2), passing-sweep at 58 (×8), tested-sweep
   when perfect (×7), composite property test (×7 cells).

## Cross-reference

Note the "tested = 58" pin should be kept in sync with:
- `crates/apr-cli/tests/cli_commands.rs::registered_commands()`
- `contracts/apr-cli-commands-v1.yaml`
- CLAUDE.md "58 subcommands" claim

Per `feedback_cli_subcommand_three_surface_drift` memory, all
three surfaces must update together when adding a new command.
QA-001's verdict pin adds a fourth enforcement layer.

## Scope

PARTIAL_ALGORITHM_LEVEL only. Wiring this into the actual
`registered_commands` test harness that produces the
`(commands_tested, commands_passing_help_smoke)` pair is
FULL_DISCHARGE work for the qa-pipeline implementation PR.

## Tests

13 unit tests, all green.