Bench: re-audit future runtime features and non-runtime exclusions #844

Follow-up of #776: X09 in the remaining exclusions and follow-ups table, finalized in #834.

Disposition: EXCLUDED unshipped/non-runtime scope.

Milestone: v3.next — Unshipped feature timing and non-runtime exclusions belong to future inventory work, not current nightly release coverage.

Remaining scope recorded by the audit:

Public profiler #185, OPFS #441 and rule persistence #241 are open/unshipped at the audited revision. Proof/test/docs infrastructure and #797's study add no shipped latency path; production uuid/dist size uses separate size gates. Re-audit new production features through the release cut.

C39/C40 and the inventory distinguish planned features from shipped latency paths:

• Public query profiler post-1.0: build query profiler #185 has no public API at the audited revision; private engine counters are not the promised public profiler.
• OPFS BrowserDb: OPFS-backed persistent mode (sync access handle, no in-memory buffer) #441 and rule persistence Rule persistence: deeper design consideration #241 are unshipped/open at the audited revision. Their eventual runtime paths need new coverage when they land.
• Kani encoder/decoder proofs, Shuttle schedules, fault/property/model tests, fuzz corpus, grammar verification, soak/envelope infrastructure and documentation/release infrastructure do not by themselves add a shipped feature latency path. Proof-only cfgs are absent from production builds.
• Evaluate shared reader code without regressing point lookups #797 is a shared-reader study, not a shipped shared-reader implementation. Its findings cannot be claimed as runtime benchmark coverage.
• Production UUID feature changes and dist size/full-LTO work (Drop the uuid "v4" feature from the library's dependencies #439/Align distribution LTO and binary-size policy with shipped artifacts #796) use separate binary-size gates/manual release-size evidence. The benchmark already uses full LTO; size verification must not be relabeled as a new Criterion feature route.

Refresh the feature inventory for every new production change through the v3.0.0 cut, then continue the same discipline for later releases. The audited v3 source is 0394c90ad90e9b95d416f4a0ec4a4c78b16e5b57 against supported v2.0.11 (709be06c391086ced67e3b0da4ab677de745ac25), with original inventory revision 4685ca9cb7638353087410c31ad07e3f6261ddb0. The audit found no production diff from that original inventory to its measured v3 revision in src/, Cargo.toml, ROADMAP.md or CHANGELOG.md; that observation does not cover later commits.

Why outside the nightly shortlist: unimplemented features have no shipped cost to measure; studies, proofs, tests and docs are infrastructure; binary size uses its own metric/gates. Keep current scope factual rather than adding placeholder timing series.

Acceptance criteria:

• Diff the audited revisions against the release-cut production source and refresh the inventory of APIs/options/features/bindings, distinguishing v3-only additions from v2 backports.
• Record shipped/unshipped status and source evidence for post-1.0: build query profiler #185/BrowserDb: OPFS-backed persistent mode (sync access handle, no in-memory buffer) #441/Rule persistence: deeper design consideration #241 at the cut; give any newly shipped runtime path an explicit benchmark/fixture/route/evidence disposition.
• Retain explicit exclusions for proof/test/docs infrastructure and Evaluate shared reader code without regressing point lookups #797 unless a production implementation lands; re-audit runtime costs if one does.
• Link separate production UUID/dist-size gate or manual size evidence, including release build settings, without claiming it as feature latency coverage.
• Carry forward unshipped feature-specific benchmark obligations to their release and link the implementing feature issues rather than duplicating implementation scope.

Run heavy builds, enumeration, measurements and comparisons on idle hardware; retain reproducible evidence and clean temporary scratch afterward. This is benchmark/verification work aligned with PHILOSOPHY.md's reliability, portability and simplicity principles; any production change needs its own review.

Evidence: docs/bench-coverage-v3.md; validation run 41642356471. The validation run establishes only its recorded representative latency coverage; it does not complete this follow-up.