Store-buffer trace repair

P102 failed in a clean way: Linux reached /init, then BusyBox faulted before the prompt after only 79 buffered user stores. P103 added a CSV trace for store-buffer accept/drain/load/trap events and compared the failed run against the P101 baseline.

The actual bug was not subtle forwarding logic. mem_req_storebuf meant “the store buffer wants the memory port”, but the arbiter could still grant writeback prefetch or background fill first. The sequential code then saw mem_ready and cleared the buffered store anyway. A requested drain was being treated as a completed drain.

The fix was to give store-buffer drains priority while an entry is pending, export mem_storebuf_grant, and clear the buffer only on:

mem_storebuf_grant && mem_ready && !mem_error

The BusyBox shell smoke now reaches P103-FILE-OK. The fixed run is a correctness PASS, not a speed win: shell-window cycles are 64,809,989 versus 64,084,050 for the same P101 baseline run. The store buffer accepted and drained 1,156,624 stores, with zero forwards because the policy still drains before fetch.

Trace file:

projects/103_storebuf_trace_repair/test/captured/2026-05-05-p103-fixed-storebuf-trace.csv

The next architectural question is whether to loosen this conservative store policy with explicit same-address forwarding tests, or move to the planned lower-memory banking/conflict rung and keep the Harvard arc visible.