docs: log real Vivado stale-source bug + final flash-bridge P&R signoff (EXP-0078)

Found and fixed a real Vivado project-management bug: two source
files (n2_system_ddr3_top.v, spi_host_bridge_v3.v) had stale imported
copies (plus a duplicate at a second path) that silently kept being
used in synth+impl despite live edits, making the first "flash bridge
included" P&R run silently synthesize the OLD design (STARTUPE2
Used=0/1 gave it away). Fixed by removing the stale/duplicate entries
and re-adding both files as direct (non-copied) references.

Final real P&R: STARTUPE2 Used=1/1 (confirms the flash bridge is
genuinely placed/routed), timing still closes but margin is now
thinner and real: WNS +0.013ns, WHS +0.032ns, 0 failing endpoints.
5213 LUTs, 16 DSP48E1.

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

hardware/v2/logs/experiments.log

@@ -4868,3 +4868,68 @@ real, not yet done, disclosed as the immediate next_action.
 next_action: real in-context P&R re-verification (synth+impl) with
 flash_spi_master.v + the new XDC pin/PERSIST constraints included --
 first real placement check for STARTUPE2 in this project.
+
+EXP-0078 -- real toolchain bug found+fixed: Vivado project had stale
+imported source copies; final real P&R with the flash bridge
+genuinely included (2026-09-19/20, same autonomous continuation)
+
+CONTEXT: after EXP-0077's flash_spi_master.v + FLASH_XFER integration,
+the first re-run of the real P&R (adding flash_spi_master.v to the
+project and re-running synth+impl) produced IDENTICAL timing/
+utilization numbers to EXP-0076's own run (same WNS, same LUT count),
+and the utilization report showed STARTUPE2 Used=0/1 -- a red flag,
+since flash_spi_master.v genuinely instantiates one.
+
+ROOT CAUSE (a real Vivado project-management bug, not an RTL issue):
+the Vivado project had IMPORTED (copied) n2_system_ddr3_top.v and
+spi_host_bridge_v3.v into NeuralProcessor.srcs/sources_1/imports/ at
+some earlier point in this session, and every subsequent `add_files`/
+`update_compile_order` call silently kept using those STALE COPIES --
+none of EXP-0077's edits (the flash bridge ports/instantiation) had
+actually reached the compiled design at all. Worse: a SECOND, separate
+duplicate copy of both files existed at a different imports/ path
+(imports/rtl/... vs imports/hardware/v3/rtl/...), from an earlier
+add_files call made from a different working directory -- real
+evidence that this kind of stale-copy drift can silently accumulate
+across a long session unless explicitly checked.
+
+FIX: diffed every one of the project's own "imports/" file copies
+against their live hardware/v3 (or v2) source on disk -- found exactly
+these two stale/duplicated files (all others were already in sync).
+Removed both duplicate/stale entries and re-added n2_system_ddr3_top.v
+and spi_host_bridge_v3.v pointing DIRECTLY at their canonical live
+path (matching flash_spi_master.v's own already-correct, non-copied
+reference) -- self-updating going forward, no import step to go stale
+again.
+
+RESULT (the real, final, trustworthy P&R): route_design 100%, 0
+errors. STARTUPE2 Used=1/1 (100%) -- confirms the flash bridge is
+genuinely placed and routed this time, not silently dropped. Timing
+still closes but with a real, measurably thinner margin now that the
+actual flash-bridge logic (including its own CCLK routing through
+STARTUPE2) is truly part of the design: WNS = +0.013ns (down from
+EXP-0076's +0.040/+0.056ns line of results), WHS = +0.032ns, still
+0/17473 failing setup endpoints and 0/17470 failing hold endpoints.
+5213 LUTs (8.22%, +40 vs EXP-0076's 5173 for the flash bridge itself),
+16 DSP48E1 (6.67%, unchanged), 0 Block RAM.
+
+DECISION: this is the current, final, genuinely trustworthy timing/
+resource signoff -- real DDR3, real pin constraints, real register
+file, real flash-bridge with real STARTUPE2 placement, all verified
+together. The margin is real but now quite thin (+0.013ns) -- any
+FUTURE logic addition to this design should be re-verified with a
+fresh real P&R before being trusted, not assumed to still close.
+
+LESSON (general, not just for this project): in any long Vivado batch-
+TCL session that repeatedly edits already-added RTL files, explicitly
+diff every "imports/" copy against its live source before trusting a
+P&R result -- `add_files`/`update_compile_order` alone do NOT
+guarantee an already-imported file gets refreshed from a later edit,
+and a stale copy produces no error, no warning, just silently wrong
+(unchanged) synthesis results.
+
+next_action: none blocking. This is a stable, real, verified
+checkpoint. Remaining open work (scaling past N=2, a real activation-
+fetch engine, PCB-specific pin constraints once the board layout is
+underway, ESP32-side JTAG bootstrap firmware) is all disclosed and
+outside this experiment's own scope.