starkernel: Phase 0 acceptance -- three-arch boot + reproducibility (item 0.10)

Adds a one-time boot diagnostic in kernel_main.c, right before sk_repl()
is entered: bounded wait for 3 real heartbeat ticks, then prints tick
count, TIME-TRUST, and variance. Needed because printing immediately
after apic_timer_start() (as first tried) measured 1 tick on amd64 and
0 on riscv64 -- not evidence the heartbeat doesn't work, just that
almost no wall time elapses between arming the timer and that point in
boot; report it honestly rather than let it stand as a false negative.

Verified this session (logs/20260804-001727, -001805, -001850,
-001948, -002021):
- All three architectures boot to ok>.
- Tick count non-zero: amd64 4, riscv64 3, aarch64 3.
- riscv64: trust=Q48_ONE exactly, variance=0 -- architecturally
  invariant counter, as designed.
- amd64: dict_hash=0x3d4e1daf289da94f, identical to the pre-item-0.8
  baseline (logs/20260803-231322) -- unchanged output, satisfying the
  GAP-A1 control.
- Two consecutive amd64 boots produced the identical dict hash --
  reproducible, no wall-clock leakage into patron state.

Phase 0 (Substrate) is complete.

Punch list §25 item 0.10 complete.

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

FABRIC.md

@@ -2157,7 +2157,7 @@ on until there is a tick on all three architectures (§16.1, §16.5).*
   *Done when:* the comment is in place. This is a documentation item; no behaviour changes.
   *Refs:* §21.2, §21.5 #1.
 
-- [ ] **0.10 — Phase 0 acceptance.**
+- [x] **0.10 — Phase 0 acceptance.**
   Full three-architecture QEMU run. Confirm: boots to prompt on all three; tick count
   non-zero on all three; on riscv64 after 0.3, trust near `Q48_ONE` and variance small
   relative to the new `expected_delta` — not merely "sane", which is unfalsifiable (C6);
@@ -2166,6 +2166,20 @@ on until there is a tick on all three architectures (§16.1, §16.5).*
   **Then boot one architecture twice and confirm the parity dict hash is identical across
   runs.** If it drifts, something is firing on wall time and Phase 0 is not complete.
   *Done when:* all of the above observed, logs committed.
+
+  > **Observed 2026-08-04.** All three boot to `ok>`. Tick count at the point just before
+  > `sk_repl()` (a bounded wait for 3 real ticks was added at `kernel_main.c` — with none,
+  > the count landed on 1 (amd64) and 0 (riscv64) purely from how little wall time elapses
+  > between arming the timer and this print, which is not the same claim as "the heartbeat
+  > doesn't tick" and would have been a false negative to report as one): amd64 4,
+  > riscv64 3, aarch64 3. riscv64: `trust=0x00010000` (exactly `Q48_ONE`), `variance=0x0`.
+  > amd64: `dict_hash=0x3d4e1daf289da94f`, identical to the pre-item-0.8 baseline
+  > (`logs/20260803-231322`) — unchanged output, as the GAP-A1 control requires. Two
+  > consecutive amd64 boots (`logs/20260804-001948`, `logs/20260804-002021`) both produced
+  > `dict_hash=0x3d4e1daf289da94f` — reproducible, no wall-clock leakage into patron state.
+  > Logs committed: `logs/20260804-001727` (amd64), `logs/20260804-001805` (riscv64),
+  > `logs/20260804-001850` (aarch64), `logs/20260804-001948` / `logs/20260804-002021`
+  > (amd64 double-boot pair).
   *Refs:* §16.4, §18.5.
 
 ---