docs: fork README; stop building the main-flavor zfs artifact

[Danathar]

Two things: adopt the fork-identity README, and turn off the artifact build added in #1 (nothing consumes it).

Stop building the artifact

zfs-aurora-complex builds its own ZFS cache from this repo's source and works fine without a published image, so a daily build of an image no one pulls is pure cost.

• images.yaml: drop *server-build-group-only-x86 from 43.main / 44.main, removing the zfs target. main is back to common, nvidia-lts, nvidia-open.
• build-akmods-main.yml regenerated — now byte-identical to its pre-feat: publish main-flavor zfs akmods from this fork #1 state, and identical to ublue-os/main. The schedule minute was preserved by hand, since the generator randomizes it on every run.
• All six Build * akmods workflows switched to disabled_manually. That's a GitHub repo setting, not a file, so it does not appear in this diff — it's recorded in FORK-PATCHES.md instead.

zfs.main in images.yaml stays. It's behaviourally a no-op (same values as zfs.default), but zfs-aurora-complex injects its own main.zfs target at build time and the Justfile reads .zfs.main.linux_experimental when building it. That block is exactly where someone would reach to silence a red ZFS build, and #2's comment explains why flipping it to true is the wrong fix.

README

Fork banner and "Why This Fork Exists", replacing upstream's heading and per-flavor build badges (which linked to ublue-os runs and said nothing about this fork).

The ghcr.io/ublue-os/... pull and cosign verify examples are deliberately left pointing at upstream. This fork publishes nothing, so rewriting them to ghcr.io/danathar/... would send readers at images that don't exist, and the checked-in cosign.pub is upstream's key. A callout above "How it's organized" says so outright.

Registry

FORK-PATCHES.md updated: T2 retired with its reasoning kept (the idea recurs), T1 rewritten to cover the surviving zfs.main block, P1 marked inert, P3 promoted now that the fork README is actually committed, operational section corrected.

It also now records a trap worth an hour of anyone's time: scheduled builds cannot succeed here at all. With no secrets set, the schedule-only Retrieve Signing Key step writes an empty KERNEL_PRIVKEY into certs/private_key.priv, making it 1 byte. build-prep.sh gates its test-key fallback on [[ ! -s ]], which a 1-byte file passes, so fetch-kernel dies on the malformed PEM:

OSSL_DECODER_from_bio:unsupported:...:No supported data to decode. Input type: PEM

That's why #1's PR run went green while all three nightlies (30318357041, 30412211886, 30503677867) failed in ~2 minutes — a green PR check does not predict a green nightly here.

Verification

After this, the only files differing from ublue-os/main are the nine with a FORK-PATCHES.md entry; images.yaml's entire delta is org: danathar plus the documented zfs.main block.

🤖 Generated with Claude Code

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 57351e4917

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Correct the retired target's contradictory history

The patch registry now says that these images were published and that images.yaml is byte-identical to its pre-change state, but the same paragraph and operational section say no image was ever published, while comparing the pre-target tree (b58bff8) with this commit shows the surviving zfs.main block and namespace changes. Since this file is intended to guide future upstream merges, describe the target as having been configured to publish and limit the restoration claim to the removed build-matrix entries.

Useful? React with 👍 / 👎.