fix(validation): support nested Git workspace roots

[saasom]

Summary

• resolve the Git prefix for a validation workspace rooted below the worktree root
• keep changed, staged, tree, tracked, and untracked listings scoped to that workspace
• translate workspace-relative file reads back to Git-root-relative object paths
• add a regression covering nested base-tree reads, sibling-change exclusion, and workspace-relative file inventories

Proof

• focused validation command adapter suite: 27 passed
• TypeScript project build: passed
• Opcore changed-file self-check with the patched CLI: passed
• Jupiter proof: patched check --changed --repo tools/geobrowser completed successfully in 5.7 seconds

Degraded coverage

• npm run ci:local reaches the Rust gate but cannot complete because cargo is not installed on this machine
• setup clean-worktree check and workspace lint passed; the full test runner also contains Rust-dependent failures for the same missing toolchain

[saasom]

For context, this surfaced while using Opcore in a monorepo where validation was intentionally scoped to one nested workspace rather than the entire Git worktree.

In that configuration, Opcore workspace paths are relative to the selected directory, while some Git operations require paths relative to the worktree root. Git listing commands also behave differently depending on the current directory and whether an explicit pathspec is provided. The result was a mismatch: before-state file reads could fail, and unrelated sibling changes could enter an otherwise scoped validation run.

The fix preserves workspace-relative paths at the validation boundary, translates them only when accessing Git objects, and explicitly limits Git discovery to the selected workspace. This should support incremental or path-scoped Opcore adoption in monorepos without depending on any particular repository layout.

The basic root-level workflow is unchanged: when the selected repo is the Git worktree root, the prefix is empty and these operations retain their existing behavior. The observable change is limited to nested --repo scopes. A caller that had unintentionally relied on a nested scope including sibling or root-level changes will now see only the requested subtree; that is a tightening of the scoped behavior rather than a change to Opcore core validation, graph, configuration, or output contracts.