Python: Harden FIDES replay and approval authority - #9876

Motivation & Context

FIDES security state must remain conservative when callers or history providers replay assistant, tool, function-result,
and approval content. Unstamped replay data, modified hidden placeholders, or caller-forged approval controls must not
inherit trust or execution authority from IDs alone.

Applications also need an explicit way to classify data added by their own context providers without adding
FIDES-specific stamping logic to those providers. This PR keeps that authority inside SecureAgentConfig and preserves
conservative behavior for data the application has not classified.

Description & Review Guide

• What are the major changes? Replay classifies unstamped assistant/tool content and data-bearing function results
  conservatively, authenticates exact session-owned hidden placeholders, and binds FIDES and ordinary approvals to
  canonical stored call bodies, exact live controls, and pending session snapshots. SecureAgentConfig accepts an
  optional synchronous message_labeler(source_id, message) callback. FIDES uses the authoritative
  SessionContext.context_messages bucket as source_id, applies the returned ContentLabel at fold points, caches it
  for the exact message object during the run, and does not mutate or stamp provider messages. SecureAgentConfig
  must follow non-history providers whose messages it classifies; explicit history providers should also precede it
  when they need application-owned labels. Ordinary history loaded later is reconstructed conservatively before tool
  policy executes. Per-service-call history that is unavailable at run setup fails closed as
  UNTRUSTED + PRIVATE.
• What is the impact of these changes? Replayed or forged content fails closed, replacement and occurrence-only
  approvals remain usable, and applications can classify their own provider data as trusted, untrusted, public,
  private, or identity-scoped. The simplification removes the provider-authority class, two one-use middleware classes,
  message stamping, and no-op replay middleware. It adds no ContextProvider lifecycle API. The new parameter is
  optional and experimental; this is not a breaking change.
• What do you want reviewers to focus on? Please review the distinction between application-owned message-label
  authority and untrusted serialized labels, the use of authoritative provider buckets rather than message attribution,
  exact-object authority through replay, and the private FIDES preflight for later-loaded ordinary history. Also verify
  that core remains the execution authority for approvals and that this change does not expand the public
  ContextProvider lifecycle. This layer intentionally excludes precise service-history continuation ownership,
  AG-UI replay provenance, and MCP result carrier behavior.

Related Issue

Fixes #9652

#9652 is the original source draft. This PR is its focused replay-and-approval-authority replacement. The policy,
state, and materialization foundation from #9875 is already present, while service-history continuation, AG-UI
provenance, and MCP carrier work remain in later replacement layers.

AI Assistance

• No material AI assistance was used.
• This is an AI-assisted contribution. I reviewed, understood, and verified all submitted content and accept responsibility for it.

AI assistance details: GitHub Copilot assisted with implementation, regression tests, documentation, and this PR
description.

Contribution Checklist

• The code builds clean without any errors or warnings
• All unit tests pass, and I have added new tests where possible
• The PR follows the Contribution Guidelines
• This PR links to an agreed issue with no competing open PR, or the Related Issue section documents a trivial-change or repository-automation exception.
• This is not a breaking change. If it is a breaking change, add the breaking change label (or add "[BREAKING]" to the title prefix, before or after any language prefix) — a workflow keeps the label and title prefix in sync automatically.