Evaluate cross-repository context for compatibility review

## Problem
Some changes are correct only relative to contracts in another repository — producer/consumer APIs, schemas, shared packages. The reviewer has no safe model for selecting authoritative external revisions or handling missing, stale, or unauthorized context.

## Goal
Research and define a minimal, permission-aware path for cross-repository compatibility review with explicit provenance and fail-closed uncertainty.

Cross-repository contract retrieval is explicitly out of scope of the delivered #175 (API/contract compatibility review) — `docs/api-compatibility/README.md` names this issue as the place that work is tracked separately.

## Scope
- Cover shared API contracts, schemas/protobuf/OpenAPI, producer/consumer compatibility, and shared libraries/packages.
- Define authoritative repository/revision selection, provenance, versioning, and release-order reasoning.
- Define stale/missing/ambiguous/inaccessible repository behavior, including when compatibility cannot be established.
- Establish security and permission boundaries for external context.
- Evaluate feasible architectures and recommend the smallest safe implementation path; record rejected alternatives.

## Non-goals
- Automatically cloning arbitrary repositories.
- An organization-wide code-search platform.
- Stacked/dependent PR behavior (already covered by #119, delivered).

## Acceptance criteria
- Supported cross-repository contract scenarios and authoritative-revision rules are documented.
- External context carries repository, revision, retrieval-time, and trust provenance.
- Missing/stale/inaccessible/conflicting context produce deterministic fail-closed outcomes.
- Security and permission boundaries prevent unauthorized context retrieval or disclosure.
- The research recommends a minimal implementation path and records rejected alternatives.

## Dependencies
Relates #118 (provenance-aware context, delivered), #119 (stacked PRs, delivered), #175 (API compatibility, delivered — this issue covers what #175 explicitly excluded).

## Validation
- Walk through producer/consumer, schema, shared-package, release-order, and missing-context scenarios.
- Threat-model repository authorization and provenance handling.
- Prototype only if the existing architecture can do so safely.