[CAG-S4] Define upstream identity and trusted metadata integration

## Why this matters

Organization rules are meaningful only if Agenova knows who is requesting the assignment and which trusted attributes apply. A user must not be able to edit ClaimRequest YAML to become a different team, select weaker company Instructions, or gain broader Policy.

Example: an upstream Entra ID/OIDC or trusted proxy may identify Alice as a member of `payments-engineering` and supply `instruction-profile=acme-payments-engineer`. Agenova should consume that verified context when authorizing `claim.create` and resolving company Instructions; Alice should not be able to self-assert either value in the task file.

The current #42 local boundary is sufficient for the deterministic demo but not a production integration contract.

## Outcome

Define a backend-neutral upstream identity/PrincipalProvider boundary and trusted metadata contract that can feed existing Policy resolution and the new Instructions selector without turning Agenova into an IdP.

## Delivery contract

- **Parent Epic:** CAG
- **Type:** Spike / contract decision
- **Builds on:** #27 (assignment authorization) and #42 (trusted local principal)

## Acceptance criteria

- Define the minimum verified principal context: subject, issuer/authentication context, groups or roles, and extensible trusted metadata.
- Define how an upstream adapter validates or receives that context and passes it separately from ClaimRequest.
- Distinguish trusted identity/resource metadata from caller-authored task labels and reject attempts to use untrusted values as authoritative selectors.
- Show how the same context feeds existing hard Policy evaluation and exact Instructions resolution without creating a coding-only identity model.
- Define failure behavior for missing, expired, malformed, wrong-issuer, and conflicting identity data.
- Define adapter trust configuration, provenance, redaction, and evidence fields without embedding upstream credentials in agent configuration.
- Recommend one thin reference integration after the local boundary, such as OIDC JWT validation or a tightly configured trusted reverse-proxy adapter.

## Evidence

- A small interface/contract proposal and trust-boundary diagram.
- Positive Team A and negative Team B/forged-metadata examples using identical ClaimRequest content.
- A threat table covering spoofing, trusted-header misuse, stale group membership, selector manipulation, and evidence leakage.
- Follow-up implementation tickets and explicit IdP/MDM non-goals.

## Non-goals

- User/password management, directory synchronization, building SSO/AD/Entra/MDM, broad device-compliance management, or full multi-tenant administration.

Start by reading the existing local principal boundary in #42 and authorization work in #27, then map how Policy evaluation and Instructions resolution consume verified context. Done means a backend-neutral contract and trust-boundary diagram, positive and forged-metadata examples, a threat table, follow-up implementation tickets, and explicit IdP/MDM non-goals.

Written by the indexing model from the issue text.