Require explicit targets and affected scope for L7 appends #3379

User Story

As an operator updating a running sandbox's policy, I want an allow or deny append to identify one endpoint and make its complete binary and port scope explicit, so that I can review exactly which access will change without replacing the whole policy.

Problem Statement

AddAllowRules and AddDenyRules identify their target only by host and one port. The modified endpoint can contain several ports and belong to a rule shared by several binaries. The append changes that entire scope, even though the request cannot declare the affected binaries and names only one port.

For example, internal_api can authorize /usr/bin/curl and /usr/bin/python3 against api.example.com on ports [443, 8443]. An allow append naming api.example.com:443 and POST /admin also grants that matcher to Python and port 8443.

When several rules or endpoint paths share the same host and port, the existing API rejects an append as ambiguous. It provides no explicit target field with which an operator can resolve that ambiguity.

Impact / Why This Matters

An operator can unintentionally grant an HTTP operation to another binary or port, or deny traffic more broadly than intended. Operators editing overlapping endpoints must replace the full YAML policy, making a small permission change harder to review and requiring them to preserve unrelated policy content themselves.

Acceptance Criteria

• Allow and deny appends explicitly identify a sandbox-owned network rule and one endpoint, including a path discriminator when required.
• A request declares every affected binary, or explicitly acknowledges an any-binary rule, and every affected endpoint port.
• Omitting one affected binary fails even when every port is declared; omitting one affected port fails even when every binary is declared.
• Missing, malformed, ambiguous, provider-owned, or stale targets fail without persisting any operation from the batch.
• A successful append changes only the selected endpoint and preserves sibling endpoints and rules.
• CLI preview, wire request, and SDK conversion preserve the same target and scope, including the distinction between an omitted endpoint path and an explicitly unscoped endpoint.
• Tests cover rejection atomicity at the gateway storage boundary and the live CLI update workflow. Documentation shows how to correct target and scope errors.

Reproduction Steps

1. Configure a sandbox-owned network rule with this network-policy portion of an otherwise valid sandbox policy:

   network_policies:
     internal_api:
       binaries:
         - path: /usr/bin/curl
         - path: /usr/bin/python3
       endpoints:
         - host: api.example.com
           ports: [443, 8443]
           protocol: rest
           access: read-only

2. With the pre-fix API, submit AddAllowRules { host: "api.example.com", port: 443, rules: [allow POST /admin] }. The equivalent pre-fix CLI invocation is:

   openshell policy update scope-example --add-allow 'api.example.com:443:POST:/admin'

3. Read the resulting policy. POST /admin is on the shared endpoint, still covering both binaries and both ports. The request contained no field declaring Python or port 8443.

4. To reproduce the target limitation independently, configure two compatible rules for the same host and port but different binary sets. Attempt the append again: it is rejected as ambiguous and cannot select either rule by name.

Environment

• OpenShell source: main 26f2f963936f68c0d5be36b34cda570d8f79f315, inspected and reproduced on 2026-09-15.
• Release context: fix(policy): prevent implicit authorization inheritance #2499 first shipped in v0.0.102; latest stable inspected was v0.0.116. The adjacent host/port append contract remains on the inspected main.

Logs