feat: memory-write index + value provenance ('when did this become 7', 'who wrote this')

[chayan-bit]

Gap

#12 (retroactive watchpoints) answers "every write to address X" by re-running a replay pass with a watchpoint armed. That is correct and it is the right primitive — but it is one pass per query. It cannot answer:

• "when did this value become 7?" (search over time for a value, not an address)
• "where did this pointer come from?" (reverse dataflow to the originating write)
• "what wrote into this struct field, ever?" (address is only known after you've already replayed)

These are the queries that make an omniscient debugger feel omniscient, and they need an index built during a single instrumented replay pass, not a scan per question.

Scope

• One instrumented replay pass over a recording that emits (seq, addr, len, old_value, new_value, thread, pc) for writes in a selected region/scope.
• Persist into the trace DB (depends on the trace-DB schema issue).
• Index by address and by value, so both writes_to(addr) and when_value_became(expr, v) are index lookups.
• Reverse-dataflow: given (seq, addr), return the write that produced the value live there. This is the primitive under "where did this come from".
• Scope control is mandatory — indexing every write in a real program is the 10-100× slowdown row in README §3.3. Default to region/allocation/type-scoped indexing, driven by the query, and cache.

Relationship to #12

#12 stays: it is the zero-index path and the honest fallback for un-indexed regions. This issue makes the common case an index hit. Do not duplicate the watchpoint mechanism — reuse it as the emitter.

Done when

when did *ptr become 7 and who wrote &foo.bar are answered from the index, with sequence numbers and logical stacks, without a fresh replay pass per query.

Ref: README §7, §1 pillar 2. Gap: queryable execution database.