ft2232h: add frame drop counter (AUDIT-C12) + cfar RMW cadence guard (AUDIT-S22)

AUDIT-C12: usb_data_interface_ft2232h had a misleading single-buffer comment
that overstated the timing slack and referenced a frame_ack_toggle CDC that
was never implemented. Re-verified actual numbers: at 178 fps the slack is
1.14 ms (20%), not "much shorter than gap". No data corruption today (write
order matches read order, addresses don't collide), but frame_complete
firing while WR_FSM is still draining the previous frame causes silent
frame drops via the missed frame_ready_toggle edge.

Fix is instrumentation, not architectural rework: add wr_done_toggle
(ft_clk -> clk CDC) on WR_DONE -> WR_IDLE, track frame_pending in clk
domain, count drops in 7-bit saturating frame_drop_count, surface in
unused upper 7 bits of status_words[5]. Host now has visibility into the
failure mode if margin ever shrinks (faster frame rate or USB bandwidth
shortfall). Replaced misleading comment with corrected timing breakdown.

AUDIT-S22: cfar_ca emits one detection per 3 cycles (THR/MUL/CMP); the
detection RMW takes 3 cycles. Match by construction today, fragile against
any CFAR speedup. Added a header comment in cfar_ca.v documenting the
dependency, and a SIMULATION-only assertion in usb_data_interface_ft2232h.v
that fires [ASSERT FAIL] AUDIT-S22 if cfar_valid arrives while RMW busy.
Catches silent-drop regressions in the test suite.

Verification: new tb_ft2232h_frame_drop.v with 5 scenarios (no drops /
stalled drops / multi-drop / recovery / saturation at 127) - 10/10 PASS.
Quick regression 31/31 PASS (was 30/30; +1 new test, 0 regressions).

9_Firmware/9_2_FPGA/cfar_ca.v

@@ -51,6 +51,21 @@
  *   = 0.55 ms. Frame period @ PRF=1932 Hz, 32 chirps = 16.6 ms. Fits easily.
  *   (3 cycles per CUT due to pipeline: THR → MUL → CMP)
  *
+ * AUDIT-S22 — DOWNSTREAM CADENCE DEPENDENCY (DO NOT BREAK):
+ *   detect_valid pulses every 3rd cycle (one per CUT triplet). The downstream
+ *   consumer usb_data_interface_ft2232h.v runs a 3-cycle read-modify-write
+ *   on the detection-flag BRAM (idle → read-wait → write-back) and silently
+ *   drops cfar_valid arriving while RMW is busy. The two cadences match
+ *   today by construction.
+ *
+ *   If you optimize this pipeline below 3 cycles per CUT (e.g., merging
+ *   ST_CFAR_MUL+CMP into a single state, or feeding the comparator
+ *   combinationally), you MUST also pipeline the RMW in
+ *   usb_data_interface_ft2232h.v to keep up — otherwise every Nth
+ *   detection is silently lost. A SIMULATION-only assertion in that
+ *   module fires `[ASSERT FAIL] AUDIT-S22: cfar_valid arrived while RMW
+ *   busy` to catch this regression in the test suite.
+ *
  * Resources:
  *   - 1 BRAM36K for magnitude buffer (16384 x 17 bits)
  *   - 1 DSP48 for alpha multiply