Ch442 review fixes: fs_edge parity, dest snap_valid, sync attrs + SDC

Codex review containment/observability fixes (no behavior change, no redesign):

- scanout_lb: add !fs_edge_v to the diagnostic predicate so capture
  matches the underflow latch's frame-start CLEAR priority exactly
  (no capture on an fs_edge cycle the real latch suppresses).
- bridge: expose a destination snap_valid_q as 0x120[0] — set ON the
  payload-capture edge, cleared on synced source-valid deassert — so
  valid never leads the bundle by a cycle (was the middle sync stage).
- bridge: forced-synchronizer (SYNCHRONIZER_IDENTIFICATION FORCED) +
  dont_merge/preserve on the underflow/read-error/valid chains;
  preserve on the bundle capture regs (both domains).
- SDC: stage-0 async cuts on the three sync[0] inputs + the 37-bit
  stable bundle hold-false-path + 2ns max_skew + 2ns net_delay, with
  fail-closed src==37 / dst!=0 count checks (tile_ram_cdc idiom).
- tb_gs_scanout_diag: +fs_edge-suppression monitor (with coverage that
  the coincidence is exercised), +valid-ordering monitor, +snapshot
  stability after later misses, +production DUT (V_SOURCE_START=32,
  stretch, linear) proving cold-start scan_y=32, +cause/phase packing.
  32/32 checks pass.
- doc: production cold start is source row 32 (not 0), base+lookahead
  may both assert, and one snapshot narrows but does not prove
  starvation vs next_fetch CDC-lag.

Sim set all PASS: focused TB, tb_ps2_hps_bridge, scanout_lb
{binomial,hstretch,psm32_256}, complete f52 replay (FB byte-identical
Z 0/307200, COLOR 0/245760). No Quartus, board, push, or scanout
behavior change.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

docs/hardware/ch441_board_validation/scanout_status_bit5_proposal.md

@@ -72,3 +72,24 @@ from "memory wrong" (write path — already ruled out for this scene by the re-d
 (A) + (B) together are minimal, add no wide arithmetic, and already partition the three
 causes for the observed persistent 0xF1. (D) is the follow-on if (A)/(B) point at the
 scanout path rather than a status artifact. Selection is deferred to owner/Codex.
+
+## Interpreting 0x120 / 0x124 on the production f52 scene (Ch442, Codex review)
+
+The A+B diagnostic is IMPLEMENTED (Ch442, RTL + SDC + focused TB, sim-only). Read the
+registers with these caveats:
+
+- **Cold start is source row 32, NOT 0.** The SH3 DISPLAY2 profile runs `V_SOURCE_START=32`
+  (DISPFB2.DBY=32) with the 15:14 vertical map, so `scan_y` begins at 32. A row-zero-miss
+  therefore reads `0x124` `scan_y≈32` / `nf_v≈32` — **not** zero. (Zero only appears in
+  synthetic `V_SOURCE_START=0` configs; the focused TB checks both.)
+- **Both cause bits may assert.** With the vertical linear/binomial filter active, a miss can
+  satisfy the base term (`scan_y>=nf_v`) AND the lookahead term (`scan_y+1>=nf_v`) at the same
+  vphase, so `0x120[3]` and `0x120[4]` can both be 1. Treat them as "which rows were short,"
+  not mutually exclusive.
+- **One snapshot NARROWS, it does not PROVE.** A single first-failure `nf_v`/`nf_s0` pair
+  distinguishes a real AXI error (`0x120[2]=1`) from an underflow (`[1]=1,[2]=0`), and locates
+  the first short row — but by itself it does **not** definitively separate a sustained
+  starvation from a transient `next_fetch` CDC-lag false positive. That separation needs the
+  later gray-code/2-cycle-agreement work (deferred), or repeated captures across frames.
+
+`bit5` at `0x02C` is unchanged; `0x118/0x11C` remain reserved.