Adopt dynamic derivations for pnpmDepsHash once Nix support is production-ready

Context

Issue #409 identified two separate tracks:

1. a short-term fix to make dt nix:hash:* update more than one stale fixed-output hash per iteration
2. a long-term design to eliminate manual pnpmDepsHash maintenance entirely

The short-term fix is being handled separately. This issue tracks the long-term design work.

Findings from #409

• The current repo has three repo-local pnpmDepsHash call sites:
  • packages/@overeng/genie/nix/build.nix
  • packages/@overeng/megarepo/nix/build.nix
  • nix/oxc-config-plugin.nix
• The shared FOD boundary is centralized in nix/workspace-tools/lib/mk-pnpm-deps.nix, so any long-term change should be designed around that helper first.
• Nix dynamic/computed derivations are technically relevant here via builtins.outputOf, but they still require experimental features such as dynamic-derivations and ca-derivations.
• Upstream tracking is still open:
  • NixOS/nix#6316 (dynamic derivations tracking issue) is still open under the dynamic-derivations stabilisation milestone.
  • NixOS/nix#8602 was explicitly called out by maintainers as necessary for practical usability/stabilisation.
• This approach would remove manual pnpmDepsHash maintenance after evaluation succeeds, but it would not solve the separate failure mode where flake.lock is itself broken and flake evaluation cannot start.
• The existing code in mk-pnpm-deps.nix already points in this direction with a TODO to replace manual FOD hashes once content-addressed / production-ready support exists.

Constraints

• Do not require unstable Nix features for downstream consumers unless we decide that intentionally.
• Keep the current staged workspace / lockfile-driven behavior intact.
• Avoid introducing a second dependency-fetch path that can drift from the real build inputs.

Proposed next steps

1. Build a narrow proof-of-concept in mk-pnpm-deps.nix that computes the dependency-store output through a generated derivation and builtins.outputOf.
2. Validate whether the design works for all current consumers (genie, megarepo, oxc-config-plugin) without changing their staged inputs.
3. Measure the tradeoff for:
   • downstream flake consumers
   • binary cache behavior
   • CI reproducibility
   • local developer ergonomics
4. Only switch the shared default once the experimental-feature requirement and upstream stabilisation risk are acceptable.

Sources

• #409
• https://github.com/NixOS/nix/issues/6316
• https://github.com/NixOS/nix/issues/8602
• https://github.com/NixOS/nix/pull/10734

Acting on behalf of the user.

Start with the TODO and shared fixed-output derivation boundary in nix/workspace-tools/lib/mk-pnpm-deps.nix, then inspect the call sites in packages/@overeng/genie/nix/build.nix, packages/@overeng/megarepo/nix/build.nix, and nix/oxc-config-plugin.nix. Build and validate the proposed proof of concept with the current staged inputs, including all three consumers. Done means the tradeoffs are documented and a shared default can be adopted without requiring unacceptable experimental Nix features.