feat(observability): identify policy and provider revisions used by a request #5396

User Story

I update OpenShell policies and providers while sandboxes are running. I need to determine which configuration a specific request actually used.

Problem Statement

Current configuration and timestamps do not reliably identify the policy, endpoint and provider revision selected by an in-flight request.

Impact / Why This Matters

A request can be investigated against a newer configuration than the one that governed it, producing misleading explanations.

Proposed Design

Capture configuration identities when a request selects them and retain those identities through its trace and security record. Use schema-safe extension fields where typed fields have different meaning, and preserve full revision precision.

Suggested UX

Inspect a request's policy generation/hash, endpoint identity and provider installation/revision, then compare requests before and after an operator update.

Acceptance Criteria

• A request retains the revision identities it actually selected, including across concurrent reloads.
• Provider and policy identities remain distinct and large revision values retain full precision.
• OCSF extension metadata remains schema-safe; no unrelated background update is invented as a child of the request.

Alternatives Considered

Joining to the latest configuration by timestamp is unreliable during reloads. Reusing typed firewall-rule version fields for unrelated identities would misrepresent their schema meaning.

Agent Investigation

The local layer pins request metadata and stores extension fields under OCSF unmapped rather than repurposing typed firewall-rule versions.

Component of #5210. This issue covers only request revisions; the tracking issue remains open for the other layers.

Checklist

• I've reviewed existing issues and the published docs.
• This is a design proposal, not a "please build this" request.