Ask for the C runtime heap's summary before play only.

The memory report's system line asked for the heap's summary at every report until one was slow. The summary holds
the heap's lock, and every malloc of every thread with it, while it adds the heap up: 54 and 70 ms in two sessions
on an RTX 5090 PC, and the frame of the first report, 30 seconds into each session, took 55 to 82 ms, the longest
frame of play in both. One slow summary switched the question off, so every session paid for it once.

It is now asked for before play only (the boot and the title screen), and at every report with mem_census = 1,
which already accepts a late frame for the walk of the address space. In play the line gives what the runtime knows
it allocated, the same figure from one report to the next. The rule is in runtime/vk_mem_heap.h with
tests/mem_heap_check, which fails against the rule before.

Co-Authored-By: Claude Fable 5.2 <noreply@anthropic.com>

docs/releases/v0.10.2.md

@@ -79,6 +79,10 @@ cards).
   frame as the scene after a later one had been named, and the upscaler then took that image for one frame. At one
   place in Kakariko with both settings as a tester had them, 51 and 52 frames flashed in two runs of 100 seconds, and
   none with the fix. Both settings stay off by default.
+- **One long frame about 30 seconds into every session** (55 to 82 ms, the longest frame of play in the two sessions
+  it was found in): the first memory report asked Windows for a summary of the game's heap, and that summary holds
+  every allocation of the game while it is taken. It is now taken before play only (`mem_census = 1` asks for it in
+  play too, for a diagnosis).
 - **Crashes and hangs found in a review of the whole runtime**; none was seen in our own play, and each fix has a check
   of its own:
   - a crash when the game read memory the lazy write-back was just handing to the GPU (NVIDIA and Intel cards);