mr status: add cross-lock-file consistency checks

Problem

When a megarepo member (e.g. effect-utils) appears as an input in multiple lock files (megarepo.lock, devenv.lock, flake.lock), these can silently drift to different revisions. There's no automated check that catches this — CI only discovers the problem indirectly when genie checks fail or nix hashes mismatch.

Concrete scenario (happened in schickling/dotfiles)

The root repo had 3 different effect-utils revisions across lock files:

megarepo.lock  →  ea35321  (ref: main)
devenv.lock    →  15e9300  (ref: schickling/2026-03-08-pnpm-gvs-boundary-spec)  
flake.lock     →  2ce79d1  (ref: main)

Additionally, devenv.yaml still pointed to a stale feature branch (schickling/2026-03-08-pnpm-gvs-boundary-spec) that had been merged long ago.

What happened in CI:

1. CI runs mr apply --all using megarepo.lock's rev → clones repos/effect-utils at ea35321
2. CI runs lint:check:genie using the genie binary from devenv.lock's rev (15e9300)
3. The genie binary at 15e9300 + repo content at ea35321 produces different output than what's committed
4. genie --check fails, lint fails
5. The actual root cause (lock drift) is completely non-obvious from the error message

This was extremely hard to diagnose — it looked like a genie staleness issue but was actually a cross-lock consistency problem.

Proposal: extend mr status with cross-lock checks

mr status already checks intra-megarepo.lock consistency (worktree drift, ref mismatches, stale locks). Extend it to also check cross-lock-file consistency.

Invariants to check

For each megarepo member that also appears as an input in the root repo's lock files:

CI integration

Run mr status (or a --check flag variant) as a CI step after megarepo sync. Exit non-zero when cross-lock drift is detected, with actionable messages like:

⚠ effect-utils: devenv.lock rev (15e9300) differs from megarepo.lock (ea35321)
  → run: devenv update effect-utils
⚠ effect-utils: devenv.yaml ref (schickling/2026-03-08-pnpm-gvs-boundary-spec) differs from megarepo.lock ref (main)
  → update devenv.yaml input URL

Alternatives considered

Option B: New mr check command — dedicated verification command with structured output. Cleaner separation of concerns but adds another command to the CLI surface. Could be warranted if the check logic becomes complex.

Option C: Integrate into mr lock / mr apply — automatically detect and warn (or --fix) cross-lock drift during lock/apply operations. Catches drift at the source but might be surprising behavior on existing commands.

Created on behalf of @schickling by Claude Code

Start by locating the mr status entry point and the existing megarepo.lock consistency checks. Review how flake.lock, devenv.lock, devenv.yaml, and flake.nix are parsed, then define checks for revision and ref drift, actionable output, and a non-zero CI result when inconsistencies are found.