Let an isolation backend reject network-policy revisions it cannot enforce #4528

User Story

I maintain an out-of-tree OpenShell compute driver whose isolation backend implements IsolationBackend and SandboxProtocol. One of its profiles gives the workload no network path at all. I need that backend to refuse a network-policy revision it can't deliver, so OpenShell doesn't report the revision as effective while every connection silently fails.

Problem Statement

• At startup the backend can refuse: at 7417f7538 it fails Attach or Confirm for any policy it can't enforce (RFC 0012, "The lifecycle").
• After StartAgent it can't: approved network-policy revisions reach the supervisor through GetSandboxConfig, and "the supervisor makes approved network-policy revisions effective through network mediation" (RFC 0012, "The lifecycle"). The backend is never asked. RequestEnvelope in proto/sandbox_protocol.proto has no request that carries a revision.
• The RFC's own rule: RFC 0012 asks each driver to "reject policy it cannot enforce" (RFC 0012, "Risks"). For revisions made after start, the protocol has no place to do that.

Impact / Why This Matters

• What breaks: in a backend whose workload has no network path, an agent can propose a rule that allows a host (RFC 0002), and a user can approve it. The supervisor then loads it and reports it effective, but every connection still fails inside the boundary.
• Who's misled: the user and the policy audit trail both see a rule that can never take effect.
• The same gap elsewhere: any backend whose mediation path can't support part of the policy vocabulary, such as certain protocols or destinations, has the same problem.
• Today's workaround: reject such policies at create time in the driver. That doesn't cover revisions proposed later.

Proposed Design

• A backend can reject an approved network-policy revision before it becomes effective.
• A rejected revision follows the existing rejection posture (RFC 0012, "The lifecycle"): the last valid generation stays effective, or network access stays denied. The rejection and the backend's reason reach the gateway, as for a revision that fails to load.
• A backend that accepts every revision needs no extra work: the default is accept.

Example of what the user sees:

$ openshell policy get demo
Revision 4: rejected by isolation backend: workload has no network path
Effective:  revision 3

Acceptance Criteria

• A backend can reject a network-policy revision after StartAgent, and a rejected revision never becomes effective.
• The rejection reason is visible to the user who approved the revision.
• Backends that don't opt in behave as today.

Alternatives Considered

• Driver-side create-time checks: these miss revisions approved after start.
• Report the rule and let connections fail: this is the current behavior, and it hides the real outcome from users and audit.
• A policy interceptor (RFC 0010): it runs at the gateway and doesn't know what the selected backend can enforce. A backend capability published to the gateway could feed one, but then the decision sits away from the component that knows.

Agent Investigation

Checked at 7417f7538: RFC 0012 ("The lifecycle" and "Risks"), and the RequestEnvelope oneof in proto/sandbox_protocol.proto. No Sandbox Protocol request carries a policy revision after StartAgent.

Checklist

• I've reviewed existing issues and the published docs
• This is a design proposal, not a "please build this" request