Fix inputs references

Unification copied the whole node onto each duplicate, which also replaced the target's `inputs`. A `follows` declaration is stored there as a list, so it was flattened into a direct reference; Nix then saw the lockfile disagree with the upstream `foo.inputs.bar.follows = "baz"` and re-locked the entry on the next evaluation, undoing the tool's work on every rebuild. Preserving the target's `inputs` wholesale trades that for a second instability. The node ends up claiming the canonical revision while declaring the old revision's input set, which Nix also re-locks, and the duplicate's own subtree stops collapsing -- which is the point of the tool. Decide per input entry instead. `unify_node` takes the canonical node whole, so the keys always match the revision being claimed, and re-grafts only the entries the target had declared as a follows. `check_lock_file` has to test the same relation for `--check` to mean "running the tool is a no-op", so it now uses `is_unified` rather than comparing whole nodes (too strict: rejects a legitimate follows) or only `locked` (too loose: misses `original` and `flake = false` divergence that `update_flake_lock` would still rewrite) Also stops aliasing one Node object into several lockfile entries, so mutating one no longer silently mutates the others. Thank you @xav-ie for reporting it;