Document that memory/allocations persist across runs (multi-export is one accreting process)

## Summary
Heap/`VirtualAlloc` allocations, dropped-file handles, and other process state persist across runs within a single emulation. This is defensible as same-process modeling, but it means "invoke every export" (`all_entrypoints=True`) is **not** a clean per-export probe — it is a single, accreting process, and later exports observe earlier exports' allocations and globals.

## Impact
Analysts and library users can misread multi-export reports as independent per-export results. Combined with the CPU-register and stack bleed issues, the cross-run coupling is stronger than expected.

## Proposed resolution (obvious — primarily documentation)
Document the semantics explicitly in `doc/reporting.md` and `doc/library.md`: runs share process-global memory by design, and (after the register/stack-reset fixes) CPU/thread context is reset per run while process memory is not. If a clean per-export probe is desired, that would be a separate opt-in feature (fresh process state per run).

## Testing / validation
N/A for the documentation change. If an opt-in "isolate runs" mode is later added: allocate in run 1, assert the allocation is absent at the start of run 2 under the isolation flag.

_Found during the architecture review on branch `claude/windows-emulator-architecture-qvaabb`._

Start by reading doc/reporting.md and doc/library.md, focusing on how all_entrypoints=True runs are described and whether process state is covered. Document that runs share process-global memory while CPU/thread context resets per run after the noted fixes. Done means both documents clearly explain the accreting-process behavior and distinguish it from a future isolated-run option.

Written by the indexing model from the issue text.