native v1 P06: hardware service image with boot-disk model inference (aienos#34, gate N3)

[aien-dev]

Refs #34 (gate N3; aien-dev/aien-architecture#190). Base: main 3c07242. Full QEMU gate run at 0022b01 (this branch on 3c07242, after #330 changed the lifecycle input path); an earlier run on ff5da2d also passed (99 checks, before the row-205 input check was added).

What changes

• Makefile: CK_INFER_LIB + CK_HARDWARE_STAGING is now allowed for exactly one image, the resident service image (CK_SERVICE=1), compiled with -DCK_INFER_DISK_ONLY=1. Supported line:
  make -C native/kernel full CK_SERVICE=1 CK_HARDWARE_STAGING=1 CK_OWNER_PUBKEYS=<file> CK_MACHINE_ID=<file> CK_INFER_LIB=<libaienos_infer_kernel.a> CK_FB_HOLD_S=120
  Still refused with hardware staging: the one-shot probe (no CK_SERVICE), CK_SERVICE_TEST_KEYS, CK_TEST_FWCFG_ARTIFACTS, every other CK_TEST_*, CK_RUST_LIBS, CK_QEMU_UNSAFE_DMA, CK_CONSOLE_SESSION, missing owner files. fwcfg_check refuses a staging inference image that contains fw_cfg, opt/aienos/model or fw_dma_read.
• core/infer.c: under CK_INFER_DISK_ONLY the fw_cfg reader is not compiled; with no MODEL.MAP the kernel prints infer: ingest REFUSED (no boot-disk model ...) and the lifecycle refuses prompt. QEMU probe and test-keys images unchanged.
• scripts/stage_one_time_boot_ck_service.sh (new): --dry-run|--apply, two clean builds with equal digests, MODEL.MAP checked against the pinned model sha, every write printed as write <dest> bytes=N sha256=H; --target-image IMG --extents ... stages a disk image (used by the gate). The machine mode is never run by this PR.
• scripts/qemu_ck_service_disk_test.sh (new): SERVICE_DISK gate, GATES.md rows 200-210. --build-only (make refusals) added to CI ck-kernel.yml.
• tools/ck_gpt_image.c: esp-model-aienos layout (ESP, model in 3 out-of-order extents, blank AIENOS partition).
• Docs: native/kernel/README.md Owner provisioning (build line, staging, proof), Makefile header, GATES.md INFER limits + SERVICE_DISK section. docs/NATIVE_PACKAGE.md not touched (w-recovery owns its new section). No core/lifecycle*.c or console receive edits.

Results

Test	Result
bash scripts/qemu_ck_service_disk_test.sh (QEMU TCG, ~25 min)	PASS, 100 checks, 0 FAIL (rows 200: 10, 201: 2, 202: 4, 203: 7, 204: 16, 205: 14, 206: 21, 207: 12, 208: 8, 209: 6)
dry run leaves the scratch disk byte-identical (cmp), apply writes the announced digests	PASS (row 203)
boot 1 unlock (recovery keyslot genesis, generated secret) -> prompt golden ids -> approve gen 4 -> remember gen 6	PASS (rows 204-205)
boot 2 cold QEMU restart on the same disk image: wrong secret refused, unlock, continuity RESUMED, recall gen 4 + fact from disk	PASS (row 206)
negative control A: no MODEL.MAP, model offered on fw_cfg -> not ingested, prompt refused	PASS (row 208)
negative control B: corrupted declared sha256 -> decode refused	PASS (row 209)
regression qemu_ck_infer_test.sh (fw_cfg probe image, at e56830c; infer.c unchanged since)	PASS
regression qemu_ck_infer_test.sh --disk (probe image, MODEL.MAP, at e56830c)	PASS (golden ids, session, every frame returned, mutated-ids control FAILs as it must)
--build-only; ck_gpt_image slots, esp-model, esp-model-aienos layouts after merging #326	PASS
CI (ck-kernel ARM64 host tests + QEMU gates, crumb, native suites)	see checks
crumb compile/verify (tool from crumb.lock d0f0b95)	OK, 91 crumbs current
Physical Spark boot, Spark NVMe AIENOS partition, owner key ceremony	NOT_RUN (hardware out of scope)

Owner files and recovery secrets in the gate are generated per run (fresh Ed25519 public key with the private half discarded, random machine id / Store uuid / secrets); no CK_TEST_* constant is used. Evidence: serial logs of the four boots kept locally by the worker (AIENOS_LOG_DIR), checked rows in GATES.md 200-210.

Remaining for N3 on hardware: attended Spark boot with the staged service image (docs/ATTENDED_SESSION_N1.md item B2), console receive path (w-console), owner key ceremony.

🤖 Generated with Claude Code