[clhodapp]

Adds the native and the upstream-compatible facter integrations, and two cost fixes. This PR is based on #96. Merge #94, #95 and #96 first, then change the base of this PR to main.

The integrations

These are my reading of "caisson-facter and facter", which you haven't confirmed. They follow the caisson-disko pattern: the parent holds the hardware, and the NixOS configurations that run on it are declared inside it.

• caisson-facter (class caisson-facter) is the hardware of a machine.
  • caisson declares facter.report, the nixos-facter report as data, and facter.reportPath, which report defaults to. It also declares assertions.
  • caisson evaluates the class with its own evalModules, so a project can add options of its own about the hardware. ch-hardware's trust grammar could become such modules; ch-hardware is unchanged here.
  • The outputs are report, checked against supportedReportVersions (today [ 1 ]), reportFile, serializableConfig (the configuration as data without caisson's options) and its hash. Every output fails with the messages of the assertions that do not hold.
  • Its machines get caisson's NixOS module caisson-facter-hardware, which sets nixpkgs' hardware.facter.report at mkDefault priority.
• facter (class facter) is a facter.json as nixos-facter writes it, named by reportPath, the only option of the class. Its machines get facter-hardware, which sets nixpkgs' hardware.facter.reportPath to that file, the line a NixOS configuration written for nixos-facter carries.

Neither is published under an output attribute set, because no tool reads a facter configuration from a flake.

The pinned-world test facterHandsTheReportToNixpkgs declares one machine inside each integration, from the report of nixpkgs' own facter test. Each machine gets the same report and the same initrd kernel modules as a nixosSystem that sets hardware.facter.reportPath itself, and the module list is checked to be non-empty. The test also checks that caisson-facter refuses a report of version 99 and a hardware an assertion refuses.

The cost fixes

Before this PR, each integration added about 110 KB to caisson's overhead in the eval-weight check, mostly in every evaluation. At that rate the six integrations still planned for slice 6 would pass the 4.28 MB ceiling. This PR has two fixes for that.

• perf(core): caisson.exports.libOverlays, caisson.exports.pkgOverlays and caisson.libOverlays.exported were attribute sets of an overlay type. So every evaluation merged each registered overlay as an option of its own, and the manifest's type check walked every overlay and its imports. These options are now merged once, by joining the definitions with //, and an entry is checked when it is read. The manifest check no longer walks the overlays.
• perf(integrations): re-export read exported and configurations for every integration in every full evaluation. It now reads them only for the integrations whose configurations a module defines, found with the new caisson.integrations.integrationsDeclaringIn, the same set childrenOf reads.

	caisson overhead
#96	4.01 MB
facter alone	4.23 MB
with both fixes	3.78 MB

The ceiling is 4.28 MB and stays there.

Checks

nix flake check passes. All 18 workspace consumers pass nix flake check --no-build with this branch in place of both caisson pins, the root input and the tests/dependencies lock. ch-system-manager is checked on clhodapp/ch-system-manager#15.

🤖 Generated with Claude Code