feat(prover): harden gateway validation for effective policy and HA execution

[zredlined]

Problem Statement

The agent-managed policy loop now wires gateway-side prover validation into agent-authored proposals (#1097), but the prover must be useful for the policy shapes and deployment modes we expect to rely on before we use it as part of automatic approval decisions.

John called out three gaps:

• Deny rules must be incorporated into prover semantics (feat(prover): support deny rules in policy verification #1061 already tracks this directly).
• Validation must branch on whether providers v2 is enabled, because that changes the effective running policy being analyzed.
• We need a clear execution model for prover workers on the gateway vs CLI side, including what works in an HA gateway deployment.

This matters for #1062 and #1434 because the policy loop is only credible if the validation result reflects the policy the sandbox will actually run, not just a convenient approximation.

Proposed Design

Keep this as a prover-hardening pass, not a new approval architecture:

• Reuse feat(prover): support deny rules in policy verification #1061 for deny-rule semantics and consume it from gateway validation once available.
• Define the authoritative input to gateway validation as the same effective policy the sandbox would receive after provider overlays and feature flags are resolved.
• Add a small effective-policy/prover fixture set that covers providers-v1 and providers-v2 branches for the same proposal.
• Decide where prover execution is authoritative:
  • Gateway-side validation is authoritative for sandbox-origin proposals and stored approval evidence.
  • CLI-side proving remains advisory/developer tooling unless it submits through the gateway path.
  • In HA, validation must be repeatable and not depend on node-local mutable state except cached solver/registry data that can be reconstructed.
• Keep outputs simple: pass/fail/unknown plus concise findings and scope notes. Do not introduce a richer evidence ontology for MVP.

Alternatives Considered

We could leave these as comments on #1062, but they are specific enough to need an owner and acceptance criteria. Splitting them into three tickets would create unnecessary sprawl; #1061 already owns deny rules, and this ticket owns effective-policy and execution-topology alignment.

Agent Investigation

• feat(gateway): persist and validate agent policy proposal operations #1097 / PR feat(policy): validate agent-authored proposals #1453 wires openshell-prover into crates/openshell-server/src/grpc/policy.rs for analysis_mode = agent_authored proposal submission.
• feat(prover): support deny rules in policy verification #1061 already tracks deny-rule support in the prover parser/model/query path.
• The current feat(gateway): persist and validate agent policy proposal operations #1097 implementation uses the latest persisted sandbox policy or sandbox spec policy plus the proposed rule. That is enough to expose prover verdicts in the workflow, but it does not yet prove that provider-v2 overlays and HA execution semantics are fully modeled.

Definition of Done

• Gateway validation uses the same effective policy branch the sandbox will run under providers v1 vs providers v2.
• Prover fixtures cover at least one proposal whose verdict differs when provider-derived policy changes the effective policy.
• feat(prover): support deny rules in policy verification #1061 deny-rule semantics are either integrated or explicitly called out in validation output as unsupported/unknown.
• Gateway-vs-CLI prover authority is documented: gateway is authoritative for approval evidence; CLI is advisory unless routed through gateway.
• HA constraints are documented and tested enough that validation does not rely on non-reconstructable node-local state.
• OpenShell Agent-Driven Policy Management #1062 is updated to reference this as a required hardening pass before broad automatic approvals.

[zredlined]

Closing this because it was opened prematurely. John's prover feedback needs to be discussed and sharpened into a specific, validated implementation need before it becomes a build ticket.