feat: gr2 exec lane-aware multi-repo build/test/run surface

[laynepenney]

Summary

Add a lane-aware execution surface to gr2 for multi-repo build, test, and run commands.

Why

Lanes are incomplete if execution stays global. Users and agents need commands to run against the correct lane and repo set without guessing.

Scope

Add lane-aware execution commands such as:

• gr2 exec status
• gr2 exec run
• gr2 exec test
• gr2 exec build

Execution should be scoped by:

• lane
• repo selection
• order/parallelism policy
• fail-fast vs collect-all behavior

Acceptance criteria

• commands run against the selected lane, not the whole workspace by default
• supports repo filtering
• records enough metadata to report what ran and where
• integrates with lane metadata rather than shell convention only

Design refs

• design: gr2 repo maintenance and multi-repo lanes #542
• docs: design gr2 repo maintenance and lanes #543

[laynepenney]

Starting the first implementation slice for lane-aware gr2 exec.

Planned first pass:

• define lane exec planning data shape against persisted lane metadata
• add a read-only gr2 exec status surface before adding execution mutation
• scope by lane first, with repo filtering and fail-fast/parallel defaults carried from lane metadata

[laynepenney]

Implemented the first read-only lane-aware exec slice locally.

What it adds:

• gr2 exec status
• lane lookup from persisted metadata
• repo filtering within a lane
• rendering of execution roots, branch intent, PR association, and fail-fast/parallel defaults

Local verification:

• cargo check -p gr2-cli --quiet
• cargo test --test cli_tests --quiet

[laynepenney]

Split the next execution slice out of this umbrella so #544 can stay focused on the exec surface rather than absorb every follow-on command.

Next concrete story: lane-aware exec run/build/test on top of the new exec status planning layer.