Add request audit envelope and propagate request id through transaction commands

[StuartFerguson]

Goal

Capture request provenance for the external REST API and propagate a stable request identifier through the command pipeline so all downstream processing can be tied back to the original audit record.

Scope for the first iteration

• Capture audit data at the API boundary for incoming requests.
• Record the request id / correlation id for every request.
• Capture caller identity from the token, including the relevant claims already used by the API.
• Capture request provenance such as source IP, user agent, route, method, and timestamp.
• Capture request-specific business context from the payload where it matters for audit.
• Pass the request id into the MediatR command / query pipeline and downstream clients so related activity can be correlated.

Suggested audit data to capture

• request_id / correlation_id
• trace_id if available
• UTC timestamp
• HTTP method and route
• source IP and user agent
• authenticated identity from the token, including estate/merchant and other useful claims
• selected payload fields relevant to the business action
• result / status code / error code

Notes

• Do not log secrets, raw tokens, or full payloads by default.
• Keep request-envelope data separate from business-context data.
• Persistence can be decided later, but the intended target is an append-only audit stream, likely KurrentDB, with retention controlled by a configurable lifetime / TTL policy.

Acceptance criteria

• A request id is available at the API boundary and is included in logs/audit data.
• The request id is passed through commands and available to downstream calls.
• At least one representative endpoint supports capturing the audit envelope and business context.
• The implementation avoids logging sensitive values such as tokens and passwords.
• The code path is ready for later storage in KurrentDB with retention managed separately.