feat(contract): expose AAR and prebind provenance through SDK and OpenAPI

[tcconnally]

Problem

The HTTP ingestion server accepts AAR and prebind fields, but the public SDK and OpenAPI contract cannot emit or discover them. At current main:

• plutus_agent/client.py:98-180 exposes no provenance/prebind parameters and forwards only legacy metering fields in local and remote modes.
• plutus_agent/server/app.py:826-839,891-903 accepts and forwards agent_id, authority/scope/intent/status/approval fields, context-render commitments, resource-constraint fields, and prebind.
• openapi.yaml:326-351 documents UsageEvent only through correction_ref and has no agent_id, action_status, or prebind properties.

A supported SDK integration therefore cannot produce the evidence contract that the server stores, and generated clients cannot discover it. This is an integration-contract gap, not an authorization bypass.

Proposed change

Define one versioned provenance/prebind contract and expose it consistently across Meter.track, local and remote SDK forwarding, /v1/usage, audit_json, and OpenAPI. Preserve optional backward compatibility and the no-raw-payload boundary.

Acceptance criteria

• Meter.track accepts and forwards the supported AAR, context-render, resource-constraint, and prebind fields in local and remote modes.
• openapi.yaml documents every accepted field, nested prebind schema, validation rules, version, and sensitive-field exclusions.
• Local SDK, remote SDK, HTTP, and direct record_usage round-trip the same hash-only fields.
• Contract parity tests prevent drift among record_usage, server ingestion, SDK, and OpenAPI.
• Legacy calls without provenance remain unchanged.
• No prompts, raw context, tool arguments, credentials, or secrets are added to durable receipts.

Grounding

• Current source: plutus_agent/client.py:98-180, plutus_agent/server/app.py:821-903, and openapi.yaml:326-351 at main commit 1a7be9a37116d9b8225b787992d38e7de0435c6.
• Related completed contracts: ledger#183, #184, #187, #188, #197, #198.
• Research lead: Atlas governed-write-gateway pattern.

Non-goals

• Ledger remains a recorder; Vault remains the authority.
• No raw prompts, context, tool arguments, credentials, or secrets.