RCA: deduplicate tsgo Nix inputs without losing compiler cache hits

Problem

Consumers that select Effect-utils' genie and effect-tsgo packages evaluate
three nixpkgs instances:

• Effect-utils' canonical nixpkgs (release-26.05)
• Effect-TS/tsgo's nixpkgs (nixos-25.05)
• Effect-TS/tsgo's nixpkgsUnstable

This is visible in a Determinate Nix sampling profile of a cold LiveStore
devenv shell. The profile is structural evidence, not an uncontended wall-time
claim: the shared benchmark host was under material load.

Evidence

At LiveStore 6fff977115465f096e4e04f4b80da622ea693a5f, with Effect-utils
99c8c7764359de121e59577e4270c1c290d6e236, the folded full-shell evaluation
profile contained 1,141 samples. Inclusive stack membership was:

Shares overlap because a sample can contain multiple frames.

A disposable lock-topology experiment exposed one root tsgo input, made
Effect-utils follow it, and made both tsgo nixpkgs inputs follow Effect-utils'
canonical nixpkgs. That removed nixpkgs_2 and nixpkgsUnstable from the
lock and reduced folded full-shell samples from 1,141 to 1,032 (9.6%).

The counter-experiment also found the main trade-off: changing follows changes
the effect-tsgo derivation identity. The existing binary-cache artifact no
longer applied and the host was still compiling effect-tsgo after 90 seconds,
at which point the bounded experiment was cancelled. A consumer-local override
therefore makes end-to-end cold setup worse and is not an acceptable fix.

Investigation goal

Find the canonical Effect-utils/Effect-TS input topology that minimizes repeated
nixpkgs evaluation while retaining the compiler's supported toolchain and a
published binary-cache artifact.

The conservative first candidate is to make only tsgo.inputs.nixpkgs follow
Effect-utils' nixpkgs, retaining tsgo's distinct nixpkgsUnstable for its Go
toolchain. The two-input deduplication experiment above is evidence of the
upper bound, not a recommendation to collapse the unstable toolchain blindly.

Acceptance

• The supported Effect tsgo build and wrapper behavior remain unchanged.
• The chosen input topology is owned in Effect-utils, not repeated by consumers.
• At least one redundant nixpkgs node is absent from a representative consumer lock.
• Repeated Nix evaluation/profile evidence improves structurally on the same revision.
• The resulting effect-tsgo and genie closures are published to the cache before consumer rollout.
• LiveStore and another Effect-utils consumer validate the shared result without local overrides.

Related consumer investigation: https://github.com/livestorejs/livestore/issues/1501

Start by inspecting the Effect-utils input topology, the tsgo nixpkgs and nixpkgsUnstable inputs, and representative consumer locks such as LiveStore's. Compare evaluation profiles and closure/cache results for the candidate topology; done means the supported tsgo wrapper and build remain unchanged, redundant lock nodes are removed, and both named consumers validate published cache artifacts without local overrides.