mara on #638: in the dashboard's inputs section, `nixpkgs` appeared
under an `agent-*` path instead of `hyperhive/nixpkgs` where the
operator expects it.
Root cause (post-#632 follows refactor):
- meta's top-level `nixpkgs.follows = "hyperhive/nixpkgs"` is a
`follows` chain, rendered in `flake.lock` as an array — the
`String` extractor in `walk_meta_inputs` correctly skips it (can't
`nix flake update` a follows alias).
- That left the root-level recursion to find `nixpkgs` only through
some other input's subtree.
- Recursion order was the BTreeMap's alphabetical key order, so
`agent-z` (or any agent starting with a letter before `h`) got
walked first and claimed `nixpkgs` at `agent-z/nixpkgs`. Hyperhive's
subsequent walk skipped `nixpkgs` (already visited).
Fix: sort `to_recurse` so hyperhive's subtree is descended first,
matching the same "hyperhive first, then alpha" priority
`read_meta_inputs` already uses for the final output ordering. Now
`nixpkgs` is claimed under `hyperhive/nixpkgs` regardless of which
agents the operator has spawned.
Added regression test covering the exact post-#632 lock shape
(`["hyperhive", "nixpkgs"]` follows array at root, agent-z
alphabetically before hyperhive). Asserts the emitted path is
`hyperhive/nixpkgs` and that `agent-z/nixpkgs` is NOT emitted (the
spanning-tree visited set guarantees one claim per node).
Closes#638.