fix: remove dead references to the deleted AUDIT_REPORT_2026-08-28.md

The audit report was intentionally deleted after its findings were applied,
but 6 backtick-quoted references to its exact filename were left behind in
DECISIONS.md, DESKRESEARCH_FINDINGS.md, PROTOCOL.md, and TODO.md — flagged
by CI's lint-docs check as dead filename references. Reworded each to plain
prose ("the 2026-08-28 project-wide audit") instead of citing a filename
that no longer exists in the repo; no content or finding-ID references were
changed.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Bjo12itgeoZW8rPFPXUZvz

Author: tedsluis

DECISIONS.md

@@ -628,17 +628,17 @@ motivated this).
 - **Status**: Accepted
 - **Note on process**: this ADR was drafted by an AI agent, but per `AGENTS.md` §6's requirement
   for explicit human/maintainer sign-off before an agent commits a new `DECISIONS.md` ADR as
-  settled: the maintainer directly reviewed `AUDIT_REPORT_2026-08-28.md`'s `GOV-01` finding and
-  explicitly approved consolidating sign-off for all findings below into one ADR (session of
+  settled: the maintainer directly reviewed the 2026-08-28 project-wide audit's `GOV-01` finding
+  and explicitly approved consolidating sign-off for all findings below into one ADR (session of
   2026-08-28). That instruction is the explicit approval this rule requires — recorded here so the
   provenance is auditable, not assumed.
 - **Context**: on 2026-08-18, `PROTOCOL.md` was updated directly from two independent capture
   sessions — `CAP-015` (EQ, completing/superseding `CAP-005`'s partial attempt) and `CAP-016`
   (Group U re-run) — promoting seven distinct claims to 🟢 FACT. Unlike every FACT promotion from
   2026-08-21 onward (`ADR-011`–`ADR-015`), these seven were never given a corresponding
   `DECISIONS.md` ADR or an explicit "maintainer sign-off obtained" citation; `PROTOCOL.md`'s
-  changelog table still marked both 2026-08-18 entries "not yet reviewed by maintainer" as of
-  `AUDIT_REPORT_2026-08-28.md`'s `GOV-01` finding. This ADR closes that gap.
+  changelog table still marked both 2026-08-18 entries "not yet reviewed by maintainer" as of the
+  2026-08-28 project-wide audit's `GOV-01` finding. This ADR closes that gap.
 - **Findings being recorded**:
   1. **EQ field-to-band mapping** (`PROTOCOL.md` §4.2): quintet field 1↔Low bass, 2↔Bass, 3↔Mid,
      4↔Treble, 5↔Upper treble (wire order is the reverse of the on-screen top-to-bottom order).

DESKRESEARCH_FINDINGS.md

@@ -164,7 +164,7 @@ Status legend (consistent with `PROTOCOL.md` §0):
 
 ### 2026-08-28 — Extraction-path (`btsnoop` vs. `btsnooz`) truncation pattern across all captures
 
-- **Trigger:** `AUDIT_REPORT_2026-08-28.md`'s `XC-01` finding — the extraction-path pattern
+- **Trigger:** the 2026-08-28 project-wide audit's `XC-01` finding — the extraction-path pattern
   (`CAPTURE_BLUETOOTH_HCI_SNOOP.md` §3's own inline PROPOSAL note, first raised from `CAP-032`'s
   single comparison against three prior sessions) is exactly the kind of "check this byte pattern
   across all existing logs" correlation this document exists for, but had never been consolidated
@@ -182,7 +182,7 @@ Status legend (consistent with `PROTOCOL.md` §0):
 
 - **Captures examined:** every capture whose own `FINDINGS.md` already documented an extraction
   path or truncation result — `CAP-012`, `CAP-013`, `CAP-017`, `CAP-031` (all `btsnooz`-extracted),
-  `CAP-032` (raw-extracted). (`AUDIT_REPORT_2026-08-28.md`'s own re-verification pass additionally
+  `CAP-032` (raw-extracted). (The 2026-08-28 project-wide audit's own re-verification pass additionally
   confirmed all other real captures — `CAP-001`–`CAP-011` excl. `012`/`013`, `CAP-014`–`CAP-016`,
   `CAP-019`–`CAP-025` — are untruncated, either raw-extracted or from a freshly-restarted log; not
   repeated here since none of those used the `btsnooz` fallback.)

PROTOCOL.md

@@ -105,7 +105,7 @@ above it.
 > RFCOMM traffic — the display is read from already-cached connection-time data, not queried live.
 > See `CAP-023-FINDINGS.md` §3–§4.
 
-> **Note (2026-08-28), `AUDIT_REPORT_2026-08-28.md` finding `XC-03` — an unrelated version
+> **Note (2026-08-28), 2026-08-28 project-wide audit finding `XC-03` — an unrelated version
 > identifier has never been reconciled against the baseline above.** `TESTPLAN_BLUETOOTH_HCI_SNOOP.md`
 > §6 states that `ANC-003` (Adaptive)/`HEAD-*`/`LOUD-001` were "added in firmware 4.467," using a
 > different-looking version scheme from this project's own confirmed `"release_5.203"` baseline
@@ -619,7 +619,7 @@ event-observation coroutines.
   group. Firmware version is confirmed at code `0x09` (per the Find Hub
   Network extension doc), sent once per Message Stream establishment. Battery
   is expected to have its own code in the same group, following the same
-  event-driven pattern; **PROPOSAL, added 2026-08-28 (`AUDIT_REPORT_2026-08-28.md` finding
+  event-driven pattern; **PROPOSAL, added 2026-08-28 (2026-08-28 project-wide audit finding
   `EXT-01`), pending maintainer review — the specific code value now has external spec support:**
   Google's official Fast Pair Device Information extension spec
   (`developers.google.com/nearby/fast-pair/specifications/extensions/deviceinformation`, fetched

TODO.md

@@ -37,7 +37,7 @@ nothing here is a second copy of that detail, only a pointer plus the reasoning
    "Open questions" section: the `CAP-021` DLCI 0x0a burst trigger and the DLCI 0x02 AES-128
    hypothesis (`PROTOCOL.md` §6) — the latter is only really testable once Phase 2 above provides
    a pw_rpc/protobuf schema to check against. **Added 2026-08-28
-   (`AUDIT_REPORT_2026-08-28.md` Phase 5), three specific new-capture ideas, none yet designed
+   (2026-08-28 project-wide audit, Phase 5), three specific new-capture ideas, none yet designed
    in `CAPTURE_BLUETOOTH_HCI_SNOOP.md`:**
    - `HOLD-005`'s Left/Right ANC-rotation-checklist split (`PROTOCOL.md` §6) — a purpose-built
      capture isolating one earbud's rotation list at a time (the envelope carries no