feat(observability): correlate credential preparation and withholding #5395

User Story

I use OpenShell providers to access separately protected APIs. I need to understand whether credentials were prepared, withheld or unavailable for a particular inspected request without exposing the credentials.

Problem Statement

A policy allow or HTTP error does not explain credential custody and preparation outcomes on the same request.

Impact / Why This Matters

Operators can confuse policy, provider and upstream authentication failures or assume credentials were used when they were withheld.

Proposed Design

Expose bounded credential-preparation outcomes as a request stage. Attach notable withholding, denial, unavailability and staleness metadata to the existing security record. Do not include tokens, secret values or exchange bodies, and retain endpoint and placement restrictions.

Suggested UX

Expand the request's credential stage and join its request ID to the HTTP Activity record. No new provider configuration or external credential service is required.

Acceptance Criteria

• Configured credential preparation and withheld/denied/unavailable/stale cases are distinguishable on the correct request.
• No credential values, token claims or exchange bodies are exported.
• Correlation does not bypass endpoint binding, credential placement checks or existing failure behavior.

Alternatives Considered

Provider configuration alone does not show what happened for one request. Upstream status codes cannot establish whether OpenShell supplied a credential.

Agent Investigation

The local layer covers static and token-grant preparation paths while preserving current endpoint and placement checks.

Component of #5210. This issue covers only credential correlation; 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.