audit schema: align published entry validation with emitted AuditEntry records #734

Context

The runtime audit-entry structure has evolved beyond the published schemas/audit-entry.schema.json. This is a follow-up to completed #47, not a reopening of its original implementation. The discrepancy was explicitly acknowledged in merged PR #723; this issue tracks whether and how to reconcile the published schema.

Source-level evidence (current default branch, 2026-10-08)

• src/cmcp_runtime/audit/chain.py defines 14 EntryType values; the schema permits 8. The six omitted values are egress_denied, suspicious_call_sequence, attestation_stale, catalog_drift, tool_observed_unadmitted, and break_glass_used.
• AuditEntry serializes detail, workflow_id, evidence_class, effective_data_class, and execution_id, none of which is declared by the schema while additionalProperties: false is set.
• Runtime non-call observations use call_id: null, whereas the schema currently requires a UUID string.
• The existing tests/unit/test_unadmitted_observation_bounds.py exercises persisted observation records, but the published schema does not permit their event type or detail field.

Evidence boundary: These are inspected source/schema contradictions, not a successful end-to-end schema-validation run and not new runtime fixture results. No runtime change, release action or normative decision is asserted.

Proposed bounded acceptance work — request for maintainer scope confirmation

1. Add a reproducible test validating an actual serialized AuditChain entry (including tool_observed_unadmitted) against the published schema; retain a conventional tool_call control.
2. Decide whether schemas/audit-entry.schema.json is intended as the normative validator for all emitted AuditEntry records. If yes, reconcile its event enum, required/nullable properties and documented optional fields with runtime serialization. Preserve additionalProperties: false and explicit types rather than allowing arbitrary properties.
3. Check both valid positive fixtures and invalid mutants (unexpected field, unsupported event type, wrong field types); do not weaken chain hashes or event semantics.
4. Keep the change confined to schema and tests, with any compatibility impact called out and reviewed independently.

Please confirm the schema's intended authority and scope before an implementation PR. This is distinct from #566's progressive discovery/checkpoint contract. No claim of implementation ownership or approved schema change is implied.