Close punch-list item #4: amd64 dict_hash non-determinism does not reproduce

Ran the amd64 kernel acceptance leg 5 times back to back as the punch
list's action item asked. dict_hash was byte-identical across every run
for every VM (Artemis, both Hermes instances, Hera/MAMA_INIT), and
matched aarch64/riscv64 exactly each time. Not jitter, and not
stable-but-different either.

The underlying mechanism the hypothesis pointed at is still real and
unchanged (capsule_dict_hash_hook() still folds execution_heat into the
hash; amd64 still runs its timer in RELATIVE mode under this
hypervisor) — but PARITY:MAMA_INIT and the child-VM PARITY:BIRTH lines
all print before the heartbeat starts, and heat only decays on
heartbeat ticks, so there's no window for the timer's non-determinism to
reach execution_heat before any of these hashes get computed. Most
likely the original 2026-07-24 observation was a one-off (loaded host
machine, coincidental timing), not a real gap.

No code change. No amendment to CLAUDE.md's acceptance criteria needed —
"identical dict_hash across all three architectures" holds up under
repeated testing. Closure note added to the punch list; the 5 verification
runs' logs and DoE CSVs are kept as the supporting evidence.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

docs/working/archive/session-logs/2026-07-24-punch-list.md

@@ -94,6 +94,32 @@ one-line amendment: "identical dict_hash across all three architectures"
 should probably be scoped to aarch64/riscv64, with amd64 checked only for
 clean boot + `PARITY:OK` + E2E PASS.
 
+**CLOSED (2026-08-02): does not reproduce.** Ran the amd64 kernel leg 5
+times back to back (`logs/20260802-074443`, `-074813`, `-075033`,
+`-075254`, `-075522`, plus the same day's earlier acceptance run at
+`-064424` — 5 runs total). `dict_hash` was byte-identical across every
+run for every VM (Artemis `0x7b29c1e7d6714051`, both Hermes instances
+`0x2e8c1b07d009507e`, Hera/MAMA_INIT `0x450998b22c298cd9`), and matched
+aarch64/riscv64 exactly in every case. Not jitter, and not
+stable-but-different either — just correct, every time.
+
+The hypothesis's premise still holds — the amd64 boot log still warns
+`invariant TSC not present under hypervisor... continuing in RELATIVE
+mode (no determinism guarantees)`, and `capsule_dict_hash_hook()`
+(`src/starkernel/capsule/capsule_vm_hooks.c:65-66`) still folds
+`execution_heat` into the hash, unchanged since this list was written.
+But `PARITY:MAMA_INIT` (and the child-VM `PARITY:BIRTH` lines) print
+*before* `Starting heartbeat...` in the boot sequence, and heat only
+decays on heartbeat ticks — so there is no window for wall-clock jitter
+to touch `execution_heat` before any of these hashes get computed. The
+mechanism is real; it just isn't reachable at this checkpoint. Most
+likely the original observation was a one-off (loaded host machine,
+coincidental timing) rather than a real gap.
+
+No code change made. No amendment to `CLAUDE.md`'s acceptance criteria —
+"identical dict_hash across all three architectures" holds up under
+repeated testing, not just the single run that first raised this.
+
 ## 5. `lfs/riscv64/starforth` isn't bit-for-bit what `make fastest` would produce
 
 The committed riscv64 LFS binary (on `master`) was built with my manual