fix(runtime): refuse successful backend claims that diverge from the plan

[doublewhy]

Plain-language summary

• Context: test(runtime): characterize backend result integrity #1150's falsification matrix probes whether the runtime boundary can refuse dishonest backend realization claims — the credibility core of "the specification is the unit of exchange."
• Problem: Four of five fabrications were admitted into the authoritative snapshot: an invented resource, a substituted resource type, a mutation reported as no change, and provisioning results filed under another domain. Only "realizes nothing" was refused (by the SEM-218 gate).
• Fix: A plan-conformance gate that holds every successful provisioning ApplyResult to the submitted plan before admission; all four lies now come back success=False with runtime.backend-contract-invalid and the untouched baseline snapshot.

Issue mapping

• Closes Characterize RuntimeManager result integrity at the backend boundary #158
• Stacked on test(runtime): characterize backend result integrity #1150 (base is 158-backend-falsification-matrix; the refusal tests are that PR's xfails flipped to hard assertions). Retargets to dev when test(runtime): characterize backend result integrity #1150 merges; rebase then.

Summary

• New raes_runtime/backend_plan_conformance.py, wired into _post_apply_contract_result after the existing snapshot-contract checks and before realization-authority disclosure. For each entry in a successful result's snapshot:
  • no plan operation at that address and the entry is new or changed → refused (invented resource / undeclared mutation);
  • resource_type differs from the plan operation → refused (substitution);
  • domain differs from the planned resource's domain (default: provisioning) → refused (cross-domain filing);
  • entry changed but its address is not in changed_addresses and the operation is not UNCHANGED → refused (undisclosed mutation).
• Scope: successful claims only. A failed apply is already non-authoritative, and its partial snapshot remains preserved for forensics — the existing contract pinned by test_provisioning_failure_preserves_provisioner_snapshot_and_skips_runtime_start. DELETE operations, and the evaluation/orchestration/stop/destroy applies (which carry no provisioning plan), are unaffected.
• The four strict xfails in test_issue_158_backend_falsification_matrix.py flip to hard assertions (refusal code + no lie in the snapshot), and the module docstring now records the closed state.
• _supplemental_realization_requirements moves to backend_realization_authority.py (next to its context type) so backend_calls.py stays under the 500-line cap.

Compatibility

• Consumer-visible tightening: a provisioning backend whose successful claim diverges from the submitted plan is now refused instead of admitted. All in-tree backends (reference, stubs, recording, libvirt, OCI) already conform — 7,011 tests pass unchanged.
• No SDL field, schema, or portable contract changes.

Verification

• Falsification matrix: 6/6 hard passes (honest control still admitted; all five fabrications refused).
• nox -s tests: 7,011 passed; branch-aware coverage gate green (the new module is exercised by the matrix plus the honest paths).
• Ruff format and lint clean; tools/check_repo_policy.py pass.

🤖 Generated with Claude Code