docs: complete architecture analysis - DDR3 bandwidth is the real ceiling, not DSP count (EXP-0080)

Before building N=4/8/16 core scaling, did the requested full
analysis. Real finding: using measured DDR3 throughput (1.24 GB/s,
from the actual EXP-0079 JEDEC trace) against calculated compute-side
need (4.96 GB/s for one core at peak DSP throughput, given the
current activation memory layout's 2x byte overhead), the system is
memory-bandwidth-bound already at N=1/N=2, not DSP-bound (only 6.67%
DSP used). Scaling core count today would show no real throughput
gain.

docs/ARCHITECTURE_ANALYSIS.md: full module review + ranked
interventions -- result-writeback engine (blocker), denser activation
packing (highest-leverage bandwidth fix), then the user's own proposed
DDRManager/orchestrator-prefetch idea (design-sketched, grounded in
neural_director_packed.v's existing job queue, explicitly scoped as
complementary to denser packing, not a substitute for it), THEN
N-scaling with real per-N P&R signoff.

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

CLAUDE.md

@@ -19,6 +19,11 @@ unmodified by v3, e.g. `layer_prefetch_ctrl.v`/`layer_weight_buffer.v`).
   timing number, and memory-layout convention needed for the physical board
   and for host (ESP32) firmware. Keep it in sync with reality — if a pin
   assignment or timing number changes, update this file in the same commit.
+- `docs/ARCHITECTURE_ANALYSIS.md` — real, measured bottleneck analysis
+  (DDR3 bandwidth is the real ceiling, not DSP count — see it before
+  proposing to scale core count) and ranked recommended interventions.
+  Update it whenever a recommendation from it gets built or a new real
+  bottleneck is found.
 - `hardware/v2/logs/experiments.log` — the real project history, one
   `EXP-NNNN` entry per real experiment/change (context/method/result/
   decision/next_action). Read the tail before starting new work; append a