refactor(arch): split release-version into installer and Flatcar axes

[mrbobbytables]

Summary

Splits project.conf's single release-version variable into two independent release axes (#125, Phase 1 of the Flatcar base migration design):

• installer-version: FSDK point release (26.08.0), describing the installer disk image and PXE inputs.
• flatcar-version: Flatcar LTS release (4593.2.5), describing the OS payload DDI and target UKI.

Details

• project.conf: replaces release-version with installer-version and flatcar-version.
• .github/scripts/check-release-version.py: rewritten to independently enforce both axes against their respective pins: installer-version against the junction ref in elements/freedesktop-sdk.bst, and flatcar-version against include/flatcar.yml.
• elements/oci/bluefin-server-ddi.bst: updates ddi-version to %{flatcar-version}.
• elements/oci/bluefin-server-installer.bst: removes the now-unneeded installer-version: "%{release-version}" override and exports the target UKI as bluefin-server-%{flatcar-version}.efi for systemd-sysupdate matching against 60-uki.transfer.
• elements/bluefin-server/os-release-flatcar.bst: derives PRETTY_NAME and IMAGE_VERSION from %{flatcar-version}.
• .pre-commit-config.yaml: updates the check-release-version hook to trigger on include/flatcar.yml.
• tests/unit/test_release_version.py: expanded to 40 unit tests covering every branch and regex of the two-axis contract, including live repository invariant checks.

Verification

• pytest tests/unit passes (228 passed, 1 xfailed).
• bats tests/unit passes.
• python3 .github/scripts/docs-checks.py passes.
• just validate passes.

Closes #125

— hive: backend=copilot model=gemini-3.8-flash

🐝 Hive Agent: contributor | SHA: 77e4211

[hanthor]

The split is correct and the reasoning holds up. I checked the consequence that worried me first: files/os/sysupdate.d/50-root.transfer matches bluefin-server-ddi-@v.raw.zst and 60-uki.transfer matches bluefin-server-@v.efi, so the DDI and the UKI must carry the same @v or A/B updates break. Moving ddi-version to %{flatcar-version} requires moving the .efi to %{flatcar-version} too, which this does. The PXE vmlinuz/initrd staying on %{installer-version} is right — they're installer media, not sysupdate targets.

Deleting the variables: installer-version: "%{release-version}" block from bluefin-server-installer.bst while leaving six %{installer-version} references resolves fine against the new project.conf declaration. Verified.

check-release-version.py runs both axes and passes:

OK: installer-version 26.08.0 matches pinned FSDK point release.
OK: flatcar-version 4593.2.5 matches pinned Flatcar release.

pytest tests/unit 228 passed / 1 xfailed. No %{release-version} remains in elements/, include/ or project.conf.

Two things to fix

1. Stale docs. Two files still name the retired variable:

docs/skills/avoid-over-engineering.md:70  "`release-version` in `project.conf`"
docs/skills/ddi-installer-build.md:93     "`installer-v<release-version>` GitHub Release."

The second is the more confusing one now that a release carries assets on two axes — worth saying explicitly that the tag tracks the installer axis while the DDI and UKI inside it track Flatcar's.

2. flatcar-version is now declared twice — project.conf and include/flatcar.yml, both "4593.2.5". The new checker keeps them in sync and just validate runs in build.yml on every PR, so this is guarded. But avoid-over-engineering.md's checklist item is literally "No hardcoded version duplicates remain," and include/flatcar.yml bills itself as the "Single source of truth." Worth a sentence in project.conf explaining why the duplicate is deliberate — otherwise the next reader deletes one of them. (bluefin-server-ddi.bst doesn't (@)-include flatcar.yml, so it reads the project.conf copy; that's the mechanism, and it deserves a comment.)

Blocking question, not about this diff

#123 §Versioning says it "supersedes both earlier proposals: the two-field split and the 26.08.XX.$FLATCARVERSION composite," and specifies that check-release-version.py should stop enforcing against the FSDK junction ref — the opposite of this PR.

I think this PR has the better of the argument: #123's own "the installer and the payload diverge in version" section is an argument for two axes, since systemd-sysinstall only exists in the installer's FSDK systemd and the installer genuinely cannot follow the payload's version. But one of the two needs to be withdrawn before either merges. I've raised it on #123 as well.

---

Generated by Claude Code