feat(v2): M4 Memory Manager + Prefetch Engine, real V1 PSRAM backend

Implements M4: memory_manager.v (arbitration/buffering/forwarding/
latency hiding/double buffering, §12) + prefetch_engine.v
(double-buffered tile fetch, §13), sitting on the REAL, UNMODIFIED V1
PSRAM backend chain (int8_memory_access.v -> memory_interface.v ->
psram_controller.v, per §15's explicit mandate not to touch the
controller).

Verified fully end-to-end with Verilator: real neural_processor (M1)
fed entirely by memory_manager, computing against PSRAM-resident X/W
tiles (double-buffered prefetch across up to 5 tiles) and writing its
result back to PSRAM -- checked via an independent PSRAM read-back,
with poison bytes around the operand regions to catch addressing
errors. 3/3 jobs pass (1/3/5-tile configurations).

Three real RTL bugs found and fixed during integration (full
diagnostic trail in errors.log ERR-0006): prefetch_engine had no
single-in-flight-request discipline, letting a queued request corrupt
the bank bookkeeping of a fetch already running; the fix's own
!pf_busy guard had a one-cycle blind spot (pf_busy lags pf_start by a
clock) that needed an explicit !pf_start term; and a state-based mux
for the shared backend port was off by one cycle, silently dropping
the PSRAM result write entirely.

Real synthesis: 0 CHECK problems, 851 LUT4/789 FF/108 CCU2C/0 DSP
(expected, no multiplication in this module). Real place&route (via a
synthesis-only timing harness, needed for the same TRELLIS_IO pin-
budget reason as M2's array): Fmax 165.86 MHz, PASS at 80MHz.

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

hardware/v2/logs/decisions.log

@@ -248,3 +248,74 @@ not merely a stylistic choice.
 
 STATUS:
 ACCEPTED
+
+---
+
+DEC-0006
+
+DATE: 2026-09-05
+
+DECISION:
+memory_manager.v (M4) uses a SINGLE prefetch_engine instance,
+retargeted per bank via a depth-1 pending-request register, rather
+than multiple engines or a general request queue. The result
+write-back (one byte per job, after the last tile) shares the same
+backend port via a simple state-based mux, not a general arbiter --
+because prefetch and write-back are temporally disjoint by
+construction (the write only happens after prefetch_engine has
+nothing left to fetch for that job).
+
+WHY:
+§13's double-buffering strategy needs at most ONE fetch "in flight"
+and at most ONE fetch "queued" at any time for a SINGLE Neural
+Processor consuming tiles sequentially (proven by construction: a new
+prefetch is only ever queued on a tile handoff, and at most one
+handoff can be pending completion of the previous prefetch before the
+next one is even requested). A general multi-entry queue or a second
+engine would add complexity with no present benefit. Likewise,
+because this Memory Manager currently serves exactly one Neural
+Processor and one job at a time, no concurrent second requester can
+ever contend for the backend port with prefetch reads -- a real
+mem_arbiter-style arbiter (as V1 uses for ITS OWN multi-master case)
+is deferred until a scenario that actually needs it exists (multiple
+Neural Processors or overlapping jobs sharing one memory_manager,
+not yet built).
+
+EVIDENCE:
+errors.log ERR-0006 -- the single-entry pending register, once
+correctly gated (see ERR-0006 items 1-2), handled 1-tile, 3-tile, and
+5-tile jobs correctly with no queue overflow in
+hardware/v2/sim/tb_memory_manager.v.
+
+ALTERNATIVES:
+1. Multiple prefetch_engine instances (one per bank), letting both
+   banks fetch fully in parallel. Rejected for M4: doubles DSP-free
+   logic for a benefit only realized when compute-tile time is
+   SHORTER than 2x fetch-tile time for a single engine -- not yet
+   measured to be the case (§22, deferred to M9), and the single-
+   engine design already fully hides fetch latency behind neural_
+   processor's own per-tile compute time in the cases tested (see
+   experiments.log EXP-0005 cycle counts).
+2. General N-entry FIFO for pending requests. Rejected: no scenario
+   in the current single-processor, single-job design can ever
+   generate more than one pending request before the in-flight one
+   completes -- an N-entry queue would be complexity with no
+   reachable use.
+3. Reuse V1's mem_arbiter.v as-is for the prefetch-vs-writeback
+   sharing. Rejected: mem_arbiter.v's four ports are hardcoded to
+   specific V1 module names/priorities (§1 already established this
+   pattern in DEC-0001 for the broader V1-freeze decision) -- and
+   prefetch/write-back are provably never simultaneous here anyway,
+   so even a generic 2-port arbiter would be unexercised complexity.
+
+RESULT:
+memory_manager.v as implemented. A NOTED, NOT-YET-OPTIMIZED
+characteristic (documented in the module's own header comment): the
+bank-swap-and-check control path costs a minimum 1 idle cycle per
+tile handoff even when the next bank was already prefetched in time,
+unlike neural_processor.v's own zero-gap tile acceptance -- left for
+M10 (Optimization) to revisit using real stall-percentage data (§22)
+rather than optimized blindly now.
+
+STATUS:
+ACCEPTED