feat(registry): S3b — apr-cli call sites resolve through the backend registry, and a static guard keeps cfg! backend reads at zero

[noahgift]

Second slice of the #3041 split, per docs/audits/pr-3041-split-plan.md (#3334). Stacked on #3342 (S3a) — until S3a merges, this PR's diff shows S3a's commits too.

S3a added the resolution library without changing any caller. This is where behaviour moves: twelve call sites stop reading cfg!(feature = "cuda") and start resolving through the registry, and a static guard keeps them that way.

What changes, and what proves each one

call site	before → after	covered by
dispatch.rs	inlined cuda check + ensure_available → run_preflight → ensure_available_for → registry::announce (FeatureDisabled 9 / BackendUnavailable 14, never a cpu downgrade)	2 new run_preflight tests
dispatch_analysis.rs	ensure_available(...) → ensure_available_for(...)	mutation-proven: reverting this single site turns every_accelerator_surface_calls_the_refusal RED, naming apr chat
accel.rs	cfg!(any(cuda,wgpu)) → registry::build_has_accelerator()	3 new tests on the switched entry point, which had none
serve/mod.rs	cfg-gated guard → ensure_accelerator_available_in(cfg, reg), fixture-driven	4 tests, now over 4 fixture registries × 20 requests instead of the build's own cfg
bench.rs, lib.rs, finetune.rs, handler_gpu_completion.rs, tests_offload_report_pp14.rs	cfg! → registry::compiled(kind) / compute_class()	existing oracles, re-pointed at the registry
handlers_include_01.rs, chat_load_tokenizers.rs, chat_generate_session_02.rs	add registry::parity_line(..) at the CUDA loads (REG-15)	cuda-only paths — named as gaps, not claimed as covered

Two gates that could not fail, found and fixed here

• The three-surface source scan searched for accel::ensure_available, which is a substring of the new ensure_available_for. It passed identically before and after the very switch it was the only oracle for.
• The new guard's own EXIT trap referenced a function-local under set -u, so it exited 1 after printing 10/10 rows.

The static guard

scripts/check_backend_registry.sh: 10 case-table rows, --self-test, and a row that copies the real accel.rs, appends a cfg!(any(feature = "cuda", feature = "wgpu")) leak, and requires the guard to go RED naming the file. bashrs: 0 errors, no pipe into grep -q.

It is ported off ripgrep to grep -rnE (plan decision D4b): no check_*.sh invokes rg, no workflow provisions it, and the clean-room runner has none — the rg form self-tests straight into env-death.

No workflow edit. The plan's S3b row listed a ci.yml --static step; decision D4(a) says it is redundant because guard_tree.sh already runs every tracked check_*.sh bare. So no-arg is the gate — a guard hiding behind --static would print usage, exit 2, and show up as a RED row for a guard that never ran. Verified: guard_tree.sh --dry-run --no-cargo lists it, and check_guards_are_wired.sh passes.

The contract's static half is restored (S3a dropped it because the guard did not exist yet — plan D2). Obligation ids are unchanged.

Deliberately left for S3c

The effective-config publication in serve/mod.rs (a0269f3), cuda_fallback_or_refuse in chat_generate_session_02.rs (5b5116d), all of run_entry.rs, and the matching contract clauses. Also left out: #3041's blobs for three files that would revert main's later ShardedSafeTensors, arch-refusal and parity_per_op work.

Gate at the final commit: apr-cli --lib 7252 passed / 0 failed, the falsifier 5/5, clippy -D warnings clean, fmt clean, the static guard 10/10, pv validate 0 errors, check_no_claim_literals ratchet 1 removed.

Refs #3041

no-close: #3041 stays open until S3c and S4 land; it is closed with a pointer then, per the plan.

ont-delta: resolves REG-OB-004 — the static-guard half (zero cfg!(feature=cuda|wgpu) backend reads outside registry.rs) leaves non_goals and is discharged by REG-F-003 via scripts/check_backend_registry.sh --static, named by the new binding_registry.static_guard row

🤖 Generated with Claude Code

[github-actions]

§13.11 rung 1 — quorum shadow verdict

S13-SHADOW pr=3344 head=6d67d2b7dce087c4f2f7de44420f911243659ba9 verdict=REFUSE class=Q1 arm_rc=1

Shadow mode: this records a verdict and merges nothing. A refusal
to arm is not a block (§13 adds zero rows to §7) — the pull request is
exactly as green as it was.

[noahgift]

stale — APR-RELEASE-001 §6, applied mechanically 2026-09-20.

No activity since 2026-09-17 13:43Z; 2 release trains have been cut since (v0.68.2, v0.68.1). Age is the only input to this sweep — it is not a judgement on the work, and a train label such as pp-066/carry-* is not an exemption.

What happens next: if one more train passes while this is still labelled stale, §6 closes it. The branch is kept — closing a PR here discards a review thread, never commits.

To clear it: push, rebase, or say on the thread what it is waiting for. Any of the three removes the label at the next sweep. If it is blocked on something external, name that here — a blocker with an owner is not sprawl, and it stops the clock.

[noahgift]

Disarmed by the aprender cop (2026-09-20 23:50Z) under tonight's review-gate ruling: every PR needs a committed AD-04 quorum receipt (docs/audits/quorum-<PMAT-issue>.json, 3/3 PASS, cross-inspected by a non-author) before it is armed. This PR was armed before the ruling and carries no receipt. Its checks were also red on stale runs (see the guard-tree rows above), so nothing changes for the merge itself; when an owner picks it up: rebase onto main, mint the fragment on the branch if pmat work status PMAT-<issue> does not resolve, run ~/.claude/skills/quorum-review/quorum-review.sh (three distinct lane models), commit the receipt, and ask for the arm.