chore(auto): update flake inputs

[void-commander-brain-freeze]

Flake update repair report

Outcome: no repairs were needed. No files were changed.

nix run .#world -- check passes on this branch (exit 0, every output ✅),
reproducing .ci-check.log exactly. nix run .#world -- lint also passes.

Rather than stop at a green check, I diffed the evaluated configuration
before and after the bump, because a green check is not evidence that
behaviour was preserved. Method: evaluate this tree twice — once with the new
lock, once with --override-input pinning nixpkgs, home-manager,
nixos-hardware and nix-darwin back to their pre-update revisions — and diff
the results.

Compared across all 11 nixosConfigurations: firewall (enable, allowed TCP/UDP
ports and ranges, trusted interfaces, reverse-path check, reject/log policy),
nftables, DHCP, nameservers, resolved, openssh (enable, ports, openFirewall,
full settings), the complete set of systemd services/timers/sockets, users,
groups, agenix secret names and their activation paths, mount points, kernel
params, initrd modules, and stateVersion. Also both darwinConfigurations
(launchd daemons and user agents, activation script keys, dock/trackpad/
NSGlobalDomain defaults, users, secrets) and both homeConfigurations (user
services/timers/sockets/targets, home and XDG file targets, session variables
and PATH, secrets).

Exactly one behavioural difference exists across the whole fleet, and it is
in the "needs a human" category — see below. Everything else is byte-identical.

Changed

Nothing. No option in this repo was renamed, removed, or changed meaning by
this update, so there was nothing to repair. No host evaluation emits a
renamed- or removed-option warning, which is the mechanical signal for an
option this repo sets having moved.

Needs a human

1. Six btrfs hosts lose three initrd checksum modules (boot / filesystems)

The only behavioural change the update produces. nixpkgs changed
nixos/modules/tasks/filesystems/btrfs.nix to gate the btrfs checksum modules
behind the kernel version:

# before
boot.initrd.availableKernelModules = [ "crc32c" ] ++ optionals (kernelAtLeast "5.5") [ ... ];
# after
boot.initrd.availableKernelModules = mkIf (kernelOlder "7.0") ([ "crc32c" ] ++ ...);

Effect: crc32c, xxhash64 and blake2b-256 drop out of
boot.initrd.availableKernelModules on alnitak, antares, cygnus, icarus,
jupiter, neptune — exactly the btrfs-root hosts, all of which run kernel
7.1.8. (sha256 stays; it is also pulled in by the LUKS path.)

Unaffected, and consistent with the gate: eris and test (bcachefs, 7.1.8),
sagittarius (bcachefs, 6.18.44), vega (ext4), installer (ISO).

Why I did not touch it:

• It is boot/initrd/filesystem territory on machines that rebuild unattended.
• It is upstream's deliberate change, applied correctly — the condition lands
  on precisely the hosts it is meant to. Re-pinning the old module list would
  mean overriding a decision nixpkgs just made, which is a choice for a person,
  not a repair.
• I verified that the gate fires as upstream intends. I did not verify
  the premise behind it — that Linux 7.x has these btrfs checksum algorithms
  built in rather than as loadable modules. That premise is what makes the
  change safe.

What a reviewer needs to decide: whether that premise holds for the kernel
these six hosts actually run. If it does, this is a no-op and the diff is
correct as-is. If it does not, six btrfs-root machines get an initrd that
cannot checksum their root filesystem, and they fail to mount root on the next
reboot — after this branch has already merged and deployed. Confirming it is
cheap: check CONFIG_CRYPTO_CRC32C, CONFIG_CRYPTO_XXHASH and
CONFIG_CRYPTO_BLAKE2B are y (not m) in the 7.1.8 kernel config before
letting these hosts take a new initrd.

2. misc/gh-release-update.nu — deprecated nushell filter (update tooling)

Off-limits by policy, so reported only. .ci-update.log shows:

filter was deprecated in 0.105.0 and will be removed in a future release.
help: `where` command can be used instead, as it can now read the predicate
      closure from a variable

It is a warning today; when nushell drops filter, the updater stops running
and flake inputs silently stop being updated. Occurrences: lines 10, 26 and 36
(the log only flags line 10, at parse time). The documented replacement is a
direct substitution — filter { |line| ... } → where { |line| ... } — which
is exactly what I would have changed, and exactly why it still needs a person:
this script decides which release URLs get pinned on every host, and a passing
build proves nothing about whether it picked the right version.

Two latent hazards in the version-selection logic that I noticed while reading
it. Both are unverified — the script chose correct versions on this run —
but they are worth a look while someone is in the file:

• Lines 26 and 36 take first from the GitHub /releases response, which is
  ordered by creation date, not by version. A backported patch release
  published after a newer minor would be selected as "latest".
• The same lines read get name (the release title, free text) rather than
  tag_name, then strip only the first "v" via str replace "v" without
  --all. A release titled e.g. VictoriaLogs v1.52.0 would not parse to a
  bare version.

3. rekey.hostPubkey warnings for test and installer (key material)

You have not yet specified rekey.hostPubkey for your host test / nixos.

Pre-existing and intentional, not caused by this update — identical in the
supplied .ci-check.log, and the warning text itself says it is expected until
a host has been deployed once. test and installer are throwaway/installer
images; all ten real hosts set hostPubkey. Untouched: this is secrets and
activation-time decryption.

4. Deprecation warnings this repo does not own

These are surfaced by the check but originate in flake inputs, so there is no
edit that can be made here. Listed so the next reader does not re-investigate:

• stdenv.isDarwin / stdenv.isLinux are deprecated. The repo has zero
  bare stdenv.is* uses — it already uses stdenv.hostPlatform.* everywhere
  (flake/packages.nix, users/profiles/*, profiles/home-manager.nix). The
  warnings come from input flakes and nixpkgs package expressions.
• Dependency of package 'rocksdb' uses a nested list in attribute 'buildInputs' — from nixpkgs/tuwunel. The repo's only rocksdb reference is
  the string database_backend = "rocksdb" in modules/my-matrix.nix, a
  runtime setting, not a build input.
• The package 'devenv-test' / 'devenv-up' is deprecated — those attributes
  are generated by devenv's own flakeModule, not declared here.
• Using 'builtins.derivation' to create a derivation named 'options.json' ... without a proper context — upstream options-documentation generation.

Coverage note

world check omits aarch64-darwin, aarch64-linux and x86_64-darwin, so it
never evaluates either darwinConfigurations — and nix-darwin made the
largest jump in this update (2026-07-30 → 2026-08-16, 17 days). It also reports
seven flake outputs as unchecked (agenix-rekey, buildkite-flake-builder,
buildkite-flake-updater, and the four github-actions-* matrices). I
evaluated all of those by hand for this update; every one is fine, and the
darwin diff above is clean apart from one new upstream option
(AppleReduceDesktopTinting) that is present but unset. Flagging the gap
because a darwin-side breakage would not show up in this branch's check.