Evergreen: support depsBuilds FOD repair in nested flakes without a root flake

Problem

evergreen fod reconcile cannot repair a known depsBuilds hash when the consumer is exposed from a nested flake in a non-flake repository root. This blocks the documented rung-1 exact-hash workflow.

Observed in schickling/schickling-stiftung for ./pi-nix#pimuseum-server:

• auto-discovery: could not determine --hash-source for pimuseum-server
• explicit hash source: could not determine --flake-ref
• explicit nested flake ref: rejected as not a supported local package attr with depsBuilds
• closure chase from the Git root prefixes .# and fails because the root has no flake.nix
• using the nested flake as repo root fails Git snapshotting because it is not a separate repository

The build uses a literal depsBuilds["."] = mkSharedHash "sha256-..." boundary.

Principled capability

Allow repair identity to be supplied or discovered as: Git repository root, nested flake path/ref, consumer attr, hash-source path relative to Git root, and install-root key. Graph metadata should remain preferred; explicit arguments should provide a fail-closed fallback with read-after-write verification.

Acceptance

• Reproduce with a Git repo whose only flake is subdir/flake.nix.
• Repair a literal depsBuilds["."] = mkSharedHash ... hash from the Git root.
• Verify only the intended hash location changed.
• Re-evaluate the consumer and confirm the declared FOD hash matches.
• Cover divergent per-system hashes without carrying an unmeasured architecture value forward.

Start by reproducing evergreen fod reconcile with a Git repository whose only flake is subdir/flake.nix, then trace how nested flake refs, hash sources, and the consumer attr are resolved from the Git root. Use the listed acceptance cases to verify the intended hash location alone changes, re-evaluation matches the declared FOD hash, and divergent per-system hashes are not carried forward.