chore(auto): update flake inputs

[void-commander-brain-freeze]

Automated flake update — repair report

Outcome: no code changes. Nothing in this update is broken, and no
deprecation warning in the logs originates in repo-owned code.

This branch is unmodified apart from the flake.lock the update itself
wrote. git status is clean.

What the update actually changed

One input, and only one:

input	from	to
nur	19d8ccc	acda571

git show HEAD -- flake.lock is a three-line diff — lastModified,
narHash, rev on the nur node. No other input moved; in particular
nixpkgs did not move, so no NixOS/home-manager/nix-darwin option can
have been renamed or removed by this update. mkRenamedOptionModule
warns and mkRemovedOptionModule throws, so a silently-dropped option is
not a failure mode available here.

nur is consumed in exactly two places, both package-level:

• flake/setup.nix:27 — inputs.nur.overlays.default, which is purely
  additive (it introduces the pkgs.nur attribute and overrides nothing).
• users/profiles/firefox.nix:12 — pkgs.nur.repos.rycee.firefox-addons.

It ships no NixOS modules into this repo, so there is no option surface
for it to break.

What I verified

• nix run .#world -- check — exit 0, 52 ✅, no errors.
• nix run .#world -- lint — exit 0.
• The warning set from my own check run is identical to the supplied
  .ci-check.log, down to the same nixpkgs store path
  (fmasn49f010z71q951x7l7cbyld8p4fl) inside the options.json
  warnings — confirming nixpkgs is unmoved and no warning is new.
• Built the six Firefox add-ons against the new NUR rev. check
  skips builds, and these add-ons are fetchurl pins that reach real
  hosts (eris, antares, cygnus, neptune) through
  users/profiles/workstation.nix. Evaluation cannot catch a dead
  add-on URL or a stale hash — only a build can. All six fetch and build:
  tridactyl-1.25.0, ublock-origin-1.74.0, privacy-badger-2026.8.7,
  duckduckgo-privacy-essentials-2026.8.6, react-devtools-6.1.1,
  adsum-notabs-1.2resigned1. This is the one place the update could
  have bitten a machine without any gate noticing, and it does not.

Why I changed nothing for the deprecation warnings

Every warning in .ci-check.log comes from a flake input, not from this
repo. I checked rather than assumed:

• stdenv.isDarwin / stdenv.isLinux deprecated — no .nix file in
  this repo uses the bare form. Grepped for
  stdenv.(isDarwin|isLinux|isAarch64|isx86_64|isMusl|isStatic): zero
  matches. It comes from inside inputs.
• devenv-up / devenv-test package deprecated — emitted by the
  devenv input's own flake-module.nix. The only mentions in this repo
  (flake/github-actions.nix:12, flake/buildkite-pipeline.nix:11) are
  CI matrix skip lists, not definitions.
• rocksdb nested buildInputs — inside the tuwunel input.
• options.json / builtins.derivation without proper context —
  input-owned.
• rekey.hostPubkey unset for test and installer — intentional
  and self-documenting; agenix-rekey's own message says this is expected
  until the host is first deployed and its pubkey read back.

None of these is fixable with a small local diff. Each would require
changing an input, and "fixing" any of them in this repo would mean
deleting or rewriting something that is not the cause — which is exactly
the failure mode this process is meant to avoid.

---

Needs a human

1. Deprecated filter in the update tooling — misc/gh-release-update.nu

This is the only deprecation warning in the logs that is genuinely
repo-owned. It appears in .ci-update.log:

filter was deprecated in 0.105.0 and will be removed in a future release.

I did not touch it, by policy, and I think the policy is right here.
The parser reports only the first occurrence (line 10), but there are
three call sites — lines 10, 26 and 36. Lines 26 and 36 are the same
expression, and it is the one that decides which release gets pinned:

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

That predicate selects the version that ends up in a URL in flake.nix
for VictoriaLogs and the two Grafana datasource plugins. A wrong choice
here — picking a prerelease, or the wrong element of $releases —
still evaluates, still builds, still merges, and pins the wrong version
on every host. A green build proves nothing about it.

• Not urgent. Pinned nushell is 0.115.1 and filter still works;
  the script ran correctly on this update, resolving 1.51.1 / 0.31.0 /
  0.25.2. This is a warning, not a break. nushell tracks top-level
  nixpkgs, which did not move in this update — so this warning is not new,
  it recurs on every run.
• What a human would have to decide: whether where with a
  closure-from-variable is exactly equivalent to filter for these
  predicates, and whether the fix should change one call site or all
  three. Line 10 (str contains) is a different shape from lines 26/36
  and may want a different replacement. Verifying that needs a run against
  the live GitHub API with the resulting pins inspected by eye — not
  something a passing build can confirm.

2. Pre-existing latent issues — not from this update, listed for context only

Neither is a regression and neither is in scope for a repair run; I am
surfacing them because they are invisible to CI, which gates only on
lint, check and the x86_64-linux package build.

• world check reports omitted these incompatible systems: aarch64-darwin, aarch64-linux, x86_64-darwin, so --all-systems
  failures never reach the gate. Under --all-systems,
  flake/packages.nix noctalia breaks on darwin — noctalia ships
  linux-only outputs. Its neighbours zwift / persway / wezterm all
  carry stdenv.hostPlatform.isLinux guards with a pkgs.hello
  fallback; noctalia was never given one. Adding a guard means choosing
  a fallback, which is a decision, not a repair.
• flake.nix still lists x86_64-darwin in systems although nixpkgs
  26.11 dropped it. No real host is affected — both darwin hosts are
  aarch64-darwin — so removing it is a cleanup with a blast radius, not
  a fix this branch needs.