Integrate FreeBSD image generation with system layer

docs/PROGRESS.md

@@ -2082,3 +2082,75 @@ Current assessment:
 
 - Phase 8.1 is now satisfied on the current FreeBSD prototype track
 - the next step is to integrate this image generation path into the declarative Fruix system-composition layer so that a single operating-system description can drive image generation end-to-end
+
+## 2026-04-01 — Phase 8.2 completed: image generation integrated into the declarative system layer
+
+Completed work:
+
+- extended the FreeBSD system module with integrated image-generation operations:
+  - `operating-system-image-spec`
+  - `materialize-bhyve-image`
+- added the Phase 8.2 integration harnesses:
+  - `tests/system/materialize-phase8-system-image.scm`
+  - `tests/system/run-phase8-system-image.sh`
+- wrote the Phase 8.2 report:
+  - `docs/reports/phase8-system-image-freebsd.md`
+- ran the integrated system-image harness successfully and captured metadata under:
+  - `/tmp/phase8-system-image-metadata.txt`
+
+Important findings:
+
+- image generation is now a direct output of the Fruix FreeBSD system-definition layer rather than an external shell-only follow-up to Phase 7
+- the integrated path now stores the resulting image artifact itself under `/frx/store`, preserving the store-centered Fruix composition story even at the VM-image layer
+- rerunning `materialize-bhyve-image` for the same operating-system description produced the same image store path, which is the current prototype proof that one declarative system object can drive image generation end-to-end
+- observed metadata confirmed:
+  - `image_store_path=/frx/store/...-fruix-bhyve-image-fruix-freebsd`
+  - `disk_image=/frx/store/...-fruix-bhyve-image-fruix-freebsd/disk.img`
+  - `closure_path=/frx/store/...-fruix-system-fruix-freebsd`
+  - `raw_sha256=ac57d4c694ea3cf6b1bd24be48982090a6cfcfa301d052c1f903636a46f2d56e`
+  - `image_size_bytes=335578624`
+  - `store_item_count=13`
+  - `esp_fstype=msdosfs`
+  - `root_fstype=ufs`
+  - `run_current_system_target=/frx/store/...-fruix-system-fruix-freebsd`
+  - `boot_loader_target=/run/current-system/boot/loader`
+  - `rc_conf_target=/run/current-system/etc/rc.conf`
+  - `rc_script_target=/run/current-system/usr/local/etc/rc.d/fruix-shepherd`
+  - `image_generation_mode=declarative-system-layer`
+
+Current assessment:
+
+- Phase 8.2 is now satisfied on the current FreeBSD prototype track
+- Phase 8 as a whole is now complete on the active FreeBSD amd64 prototype path
+
+## 2026-04-01 — Phase 8 completed on the current FreeBSD prototype track
+
+Phase 8 is now considered complete for the active FreeBSD amd64 prototype path.
+
+Why this milestone is satisfied:
+
+- **Phase 8.1** success criteria were met on the prototype track:
+  - a reproducible raw GPT+UEFI+UFS image can now be generated from the Fruix system outputs
+  - that image passes static boot-structure sanity checks
+- **Phase 8.2** success criteria were met on the prototype track:
+  - the image builder is now integrated with the declarative Fruix system-definition layer
+  - a single operating-system description now drives image generation end-to-end
+  - the integrated output is itself a store-backed Fruix image artifact under `/frx/store`
+
+Important scope note:
+
+- this completes the **image-construction milestone** for the current prototype track, not the first successful bhyve boot yet
+- the generated image is now ready for the next phase’s VM-launch and serial-console validation work
+- the current first-boot strategy remains explicit and unchanged:
+  - FreeBSD init + `rc.d` + Shepherd
+- the image path still reflects the current prototype system/runtime limitations, including the fact that deeper runtime closure completeness for locally copied Guile/Shepherd dependencies will be exercised more fully in Phase 9 boot validation
+
+Next recommended step:
+
+1. begin Phase 9.1 by creating a bhyve launcher and serial-console validation harness for the generated image
+2. keep the current deterministic ready-state target visible:
+  - Shepherd startup leading to the generated `/var/lib/fruix/ready` marker path
+3. continue preserving the selective Fruix naming policy:
+  - Fruix at the product boundary
+  - `/frx` as the canonical store root
+  - stable upstream-derived internal names unless there is strong architectural value in renaming them