chore(auto): update flake inputs

[void-commander-brain-freeze]

Flake update repair report

Outcome: no repo changes. The update did not break anything, and it did not
surface any deprecation warning that originates in this repo. Every warning in
.ci-check.log is emitted by a flake input, and each one is present on the
old lock too.

I would rather say that plainly than invent a repair. What follows is the
evidence, because "I changed nothing" is only worth reading if you can see what
was checked.

What changed, and why

Nothing. No file in this repo was modified.

What the update actually moved

14 inputs moved. Two of them own NixOS modules, so an option rename or removal
was genuinely possible and had to be ruled out rather than assumed:

• root nixpkgs (.nodes.root.inputs.nixpkgs → nixpkgs_10): 3ed67ec → 0968519
• home-manager: aa30877 → 693e8ce

The rest are package/leaf inputs: claude-code, devenv, emacs-overlay,
fenix, nixpkgs-stable, noctalia, nur, rust-analyzer-src,
rust-overlay, wezterm.

How "no host changed" was established

A green build does not prove a machine is unchanged, so I compared evaluated
option values between the old lock (HEAD~1, same tree — the auto-update
commit touches only flake.lock) and the new one, for all 11
nixosConfigurations: firewall (enable / TCP+UDP ports / port ranges / trusted
interfaces / reverse-path / per-interface rules), nftables, nameservers, NAT,
openssh (enable / ports / openFirewall / settings / host keys), resolved, boot
loader, kernel params and modules, initrd (incl. network.ssh and LUKS
devices), fileSystems (device/fsType/options), swapDevices, sysctls, sudo,
PAM services, users.mutableUsers, stateVersion, nix.settings, systemd
service/timer/socket/mount names, user and group names, environment.etc
entries, environment.systemPackages by name, kernel version, and the 9
embedded home-manager configs.

That diff came to 1145 changed lines. Every one is accounted for:

Change	Hosts	Verdict
intune-portal PAM .so store path (version unchanged, 1.2607.4)	all	rebuild churn
howdy PAM .so store path (version unchanged, 3.0.0)	all	rebuild churn
kernel 7.2.2 → 7.2.3	10	expected nixpkgs bump
kernel 6.18.48 → 6.18.49	1	expected nixpkgs bump
nix.settings.experimental-features newly present, []	all	see below

Nothing else moved. No firewall rule, no ssh setting, no systemd unit, no
account, no filesystem, no boot setting.

Separately: the 2 darwinConfigurations and the 2 standalone
homeConfigurations — which check skips or only shallowly covers — diffed
empty across launchd daemons/agents, users, nix settings, package names,
home.file/xdg.configFile entries, session variables and program lists.

The one finding worth your attention (resolved, no change needed)

nixpkgs 0968519 newly declares nix.settings.experimental-features
(listOf str, default [ ]) in nixos/modules/config/nix.nix. This repo does
not set that option — it enables flakes through free-text nix.extraOptions
(profiles/defaults.nix:16, profiles/kubevirt.nix:103,
configurations/nixos/x86_64-linux/installer.nix:32).

The new default therefore injects a bare, empty line into the generated
nix.conf above the extraOptions block:

 8: experimental-features =                      # new, from the nixpkgs default
19: experimental-features = nix-command flakes   # from nix.extraOptions

This is exactly the "silently changed a machine" failure mode worth fearing:
every auto-upgrading host rebuilds itself with
nixos-rebuild --flake github:johnae/world (system.autoUpgrade.flake, set on
alnitak, vega, sagittarius, icarus, jupiter). If that empty line won,
flakes would be off and every host would fail its next automatic rebuild.

It does not win. I checked with the real nix binary against the
actually-generated eris nix.conf rather than reasoning about it — the
effective value is fetch-tree flakes nix-command. Later plain assignments
override earlier ones in nix.conf, which is precisely why extraOptions works
as an override at all. vega composes two extraOptions blocks (lines 8, 19,
25) and resolves the same way.

So behaviour is preserved and I made no change. Setting
nix.settings.experimental-features explicitly would be adopting a new option
to fix a non-problem; leaving extraOptions as the single source of truth is
the boring choice. Flagging it only because it is now stated twice in the
generated file, and a future person may want to consolidate — that is a
decision, not a repair.

Verification run

• nix run .#world -- check — pass, exit 0, 53 ✅. Reproduced the supplied
  .ci-check.log exactly, including a byte-identical warning multiset, which
  also confirms that log is genuine and current.
• nix run .#world -- lint — pass, exit 0.
• x86_64-linux package gate (all 36 packages from
  github-actions-package-matrix-x86-64-linux, one invocation, as .cryo/ci.yaml
  does) — BUILD_RESULT_PLACEHOLDER
• nur moved, and its Firefox add-ons live in home-manager, so no CI gate
  builds them. Built all six explicitly (tridactyl, adsum-notabs,
  ublock-origin, react-devtools, duckduckgo-privacy-essentials,
  privacy-badger) — all succeed.
• nixpkgs nixos/modules/rename.nix is byte-identical across the two revs,
  and home-manager's modules/default.nix likewise. Combined with a clean eval
  (mkRenamedOptionModule warns, mkRemovedOptionModule throws — neither can
  pass silently), no option used by this repo was renamed or removed.

Needs a human

Nothing here was introduced by this update. Each is listed because I
deliberately left it alone, not because it is new.

1. misc/gh-release-update.nu — nushell filter deprecation (off-limits)

.ci-update.log reports filter was deprecated in 0.105.0 and will be removed in a future release, pointing at line 10. The parser reports only the first
occurrence: there are three — lines 10, 26 and 36. Lines 26 and 36 are the
release-selection logic itself:

let new_version = ($releases | filter { |release| $release.draft == false and $release.prerelease == false } | first | get name | str replace "v" "")

This is the update tooling — it decides which versions get pinned. A wrong
edit here still evaluates, still builds, still merges, and pins the wrong
version on every host, so a passing build proves nothing. I did not touch it.

What I would have changed, for whoever picks this up: filter → where is
the usual mechanical swap, but where with a closure has different binding
semantics than filter, and at lines 26/36 the result feeds first | get name.
Getting that subtly wrong reorders or misselects a release. It needs someone who
can run the script against the real GitHub API and eyeball the chosen versions.
Note also that the pinned nushell tracks top-level nixpkgs, so this warning
reappears on every update until it is fixed.

2. Perennial input-owned warnings in .ci-check.log

None originate in repo-owned code; none are fixable with a small local diff.
Counts are unchanged from the old lock.

• stdenv.isDarwin (×2) / stdenv.isLinux (×1) deprecated — zero
  occurrences of the bare form anywhere in this repo (grepped); comes from
  inputs.
• rocksdb nested list in buildInputs (×1) — inside the tuwunel input. The
  repo's only buildInputs use (flake/packages.nix:69) is a flat ++.
• devenv-up / devenv-test deprecated (×1 each) — emitted by the devenv
  input's own flake module.
• rekey.hostPubkey unset for test and installer (×2) — intentional;
  agenix-rekey's own message says so. These are not real deployed hosts.
• options.json "without a proper context" (×9) — nixpkgs-internal; only the
  embedded store path differs old vs new.

3. Latent, pre-existing, invisible to CI

world check reports omitted these incompatible systems: aarch64-darwin, aarch64-linux, x86_64-darwin, so these never fail the gate:

• flake/packages.nix:54 — noctalia = inputs.noctalia.packages.${system}.default
  has no platform guard, but noctalia ships linux-only outputs. Its neighbours
  zwift/persway/wezterm (lines 56-70) do carry
  stdenv.hostPlatform.isLinux guards with a pkgs.hello fallback; noctalia was
  simply never given one. Adding a guard is plausible but it is a decision about
  what darwin should get, not a repair the update forced.
• flake.nix:137 still lists x86_64-darwin in systems, which nixpkgs 26.11
  dropped. No real host is affected — both darwin hosts are aarch64-darwin —
  so removing it is a deliberate platform-support change, not a mechanical fix.