Update 10016 copies the moved audit settings but leaves the originals behind as silent no-ops

Problem/Motivation

mcp_sentinel_update_10016() copies audit_hash_key, audit_encryption_profile and siem_enabled into audit_chain.settings, then leaves the originals in mcp_sentinel.settings. Nothing reads them any more — McpMetrics, McpUrgentConditions and McpSettingsForm all read audit_chain.settings now.

Steps to reproduce

Upgrade a 1.13.x site to 2.0.0, run updates, export configuration. mcp_sentinel.settings.yml still contains:

audit_hash_key: mcp_audit_hmac
audit_encryption_profile: mcp_audit
siem_enabled: true

alongside the identical values in audit_chain.settings.yml.

That leaves configuration which looks like it controls the signing key and does not. An operator editing audit_hash_key there — or deploy automation setting it — gets a silent no-op. It is the same "configuration asserting an unenforced control" shape this release was largely about fixing elsewhere, reintroduced by an incomplete migration.

It also invites real drift: two copies of a signing-key reference that can disagree, with only one of them consulted.

Proposed resolution

• clear() the three keys in the update hook after copying them across, and remove them from config/schema/mcp_sentinel.schema.yml so they cannot return.
• Add a follow-up update hook for sites that already ran 10016 — they exist — since editing 10016 in place will not re-run it.
• Check whether siem_enabled should remain presented as an MCP-level toggle. The settings form still shows it under Audit Logging, which is right for the operator, and it now writes through to audit_chain.settings:stream_enabled. If it stays presented here it must remain a write-through and never a stored copy.

Remaining tasks

Implementation notes: mcp_sentinel issue 72.