Egress DLP block is reported as an environment variable capability error (EGRESS_SECRET_LEAK_BLOCKED) #44

When egress DLP blocks an outbound request because it carries a registered audit secret, the violation is reported as an environment-variable capability error instead of an egress DLP violation. The blocking works; only the classification and message are wrong. This is the second problem described in #9, which was closed after the --audit-egress=auto part was fixed.

Repro

SLICE_AUDIT_EGRESS=sk_live_topsecret_9 slice mcp --allow-net=example.com

{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2024-11-05","clientInfo":{"name":"repro","version":"1"}}}
{"jsonrpc":"2.0","id":2,"method":"tools/call","params":{"name":"slice_eval_ts","arguments":{"code":"Slice.mockFetch(\"https://example.com/x\", {status:200, body:\"ok\"}); Slice.fetchSync(\"https://example.com/x?k=sk_live_topsecret_9\").status"}}}

The same message appears for secrets registered with --audit-egress=<secret>, --audit-egress=auto (from .env), and the auditSecrets argument of slice_eval_ts.

Expected: a violation that names the cause, for example Egress DLP Violation: Compartment 'mcp-agent-host:sub' outbound request to 'example.com' carried a registered audit secret; request blocked. Ideally a dedicated SandboxViolation variant (for example EgressSecretBlocked { tenant_id, host }) so embedders can match on it.

Actual

"violation":"OCap Violation: Compartment 'mcp-agent-host:sub' lacks environment variable authority for key 'EGRESS_SECRET_LEAK_BLOCKED'"

Why it matters: the message points users to environment-variable permissions, which have nothing to do with the cause, and embedders have to string-match the sentinel key EGRESS_SECRET_LEAK_BLOCKED inside SandboxViolation::EnvAccessDenied to recognize a DLP block.

Environment

• Version: v0.10.6, commit c6b3e77
• OS: Windows 11 x64, release build (cargo build --release)