Spike: is the squashfs packaging/publish step in CI used by anything, or dead cost?

## Type
Spike / investigation (time-boxed). Deliverable is findings + a decision (keep / remove / replace), with a follow-up PR if action is needed.

## Background
Each build job in `.github/workflows/build.yml` (FreeBSD, Arch, Debian — and the OpenBSD job from #33) packages the installed system and uploads it as an artifact. The packaging includes:

```
tar -C / -cJf .../system.txz /System
mksquashfs /System .../Gershwin--.squashfs -comp xz -b 1M
... (dependencies list + tree index.html) ...
- uses: actions/upload-artifact@v4
```

## Observation / problem
The `mksquashfs ... -comp xz` step adds **~3+ minutes per job** (xz compression of the entire `/System` tree), and the resulting `.squashfs` artifact does **not appear to be consumed by anything** — there is no release pipeline, ISO/live-media build, installer, or downstream job that downloads or publishes it. It is uploaded and then expires unused.

If that's accurate, it's pure cost: CI minutes (×4 OS jobs, every push/PR) and artifact storage, for an output nobody uses.

## Spike questions
1. Does **anything** consume the `.squashfs` artifact? (release workflow, live-media / ISO build, installer, a downstream repo, a manual process, docs/links). Search this repo, org workflows, and any release/website tooling.
2. Was it intended for a **future** flow (live ISO / installer image) that isn't wired up yet? If so, is that planned soon, or speculative?
3. Which artifact is actually the useful one — the `.txz` tarball, the `.squashfs`, both, neither?
4. If we keep an image artifact, is `-comp xz` the right tradeoff, or would `zstd`/`lz4` give acceptable size at a fraction of the time?

## Options
- **Remove** the `mksquashfs` step (and possibly the whole packaging/upload block) if nothing consumes it — fastest CI, less storage.
- **Keep but cheapen** — switch `-comp xz` to `zstd`/`lz4` to cut the ~3 min while retaining an image.
- **Wire it up** — if a live-media/installer flow is intended, connect the artifact to an actual publish/release so it serves a purpose.

## Acceptance criteria
- [ ] Documented whether the `.squashfs` (and the broader packaging/upload block) is consumed by anything today.
- [ ] Documented whether it's intended for a planned future flow.
- [ ] Decision recorded: keep / cheapen / remove, with rationale and a follow-up PR if action is taken.

## References
- `.github/workflows/build.yml` (the `mksquashfs` / `upload-artifact` steps in each OS job)
- Related: #33 (OpenBSD job carries the same packaging block)