fix(pingora): scope Nginx required gate to owned edge-runtime responsibilities

[seonghobae]

Finding

The current organization-required Pingora gate has a live responsibility-boundary contradiction that can force product-local static serving into the shared edge migration even when no shared Ingress/Edge Routing/TLS/HTTP Policy/Load Balancing responsibility has been established.

Protected .github/main@43024633eba9d96b0456970391360da5a171fbda currently says two incompatible things:

1. docs/policies/PINGORA_EDGE_POLICY.md declares every production/test active Nginx container, package, command, config, ingress class/annotation and host service prohibited, explicitly says the organization maintains reusable Pingora static-serving artifacts, and provides no standing Nginx exception.
2. Existing owner handoff [Context Fabric handoff] Admit Pingora edge migrations as versioned EA projections #1608 says static-file Nginx containers such as scopeweave, LineageWeave, and inkspan are not automatically shared-edge migrations merely because they use Nginx; responsibility boundary must be proven before adding them to the queue.

The executable scanner currently implements the broader rule, not the bounded one. Fresh exact-head source is scripts/ci/pingora_edge_policy.py@43024633... (blob 33e58ed87616c71951b74a1da0044b4894bcc756). _needs_content_scan() always scans changed Dockerfile/Containerfile/compose/config candidates and evaluate_pull_request() then loads the final exact-head file content and passes it to scan_content(). Therefore a product that already uses Nginx only as a static-file server can have an otherwise unrelated Dockerfile maintenance PR rejected solely because the unchanged final file still contains FROM nginx....

This is not a request to weaken a public-edge migration gate. It is a DDD/ownership repair: shared Pingora policy should govern actual shared edge-runtime authority, while product static build/serving remains product-owned unless an explicit migration contract promotes that responsibility into the canonical edge bounded context.

RED acceptance

Add owner tests that demonstrate the current false-positive boundary without relying on an exception allowlist by repository name:

• a changed product Dockerfile whose final exact head is a static-only Nginx image (COPY dist -> /usr/share/nginx/html, no reverse proxy, ingress controller, TLS termination, upstream routing, auth/business policy) must not be classified as a shared-edge migration solely from the image/runtime vocabulary;
• a changed Dockerfile/config that carries reverse proxy/upstream routing, Nginx ingress-controller authority, public TLS/HTTP edge policy, or executable Nginx gateway behavior must remain fail-closed until its approved Pingora migration contract exists;
• an existing static runtime must not be able to smuggle proxy_pass, ingress-controller, TLS-edge, upstream-routing, or other newly edge-owned behavior through the static classification;
• policy decisions must be based on an explicit responsibility/profile contract or bounded structural evidence, not per-repository hard-coded exemptions.

Minimal repair direction

Keep .github as the sole owner of the required workflow/scanner, but split the policy conceptually into:

• edge-runtime candidate detection: reverse proxy/upstream routing, ingress controller, public listener/TLS ownership, edge HTTP policy/load balancing or an explicit versioned migration declaration;
• static product-serving/runtime evidence: product-owned static artifact serving that is not automatically promoted into pingora-gateway.

A versioned owner contract/profile is preferable to heuristics alone. The gate should still fail closed when evidence is incomplete or when a static profile gains edge behavior. Do not solve this by a broad scanner skip, a repository-name allowlist, required-workflow weakening, or retaining runnable Nginx as a rollback mechanism after a real edge cutover.

GREEN / integration evidence

Before closure require:

1. owner RED→GREEN tests for static-only versus actual edge-runtime cases;
2. docs/policies/PINGORA_EDGE_POLICY.md, ADR 0019, doctoring/TRACEABILITY and .github#1608 to state one consistent bounded-context rule;
3. required-workflow exact-head tests and full policy coverage GREEN;
4. fresh organization scan showing true reverse-proxy/ingress/TLS edge candidates remain gated while static-only product containers are not automatically queued as shared-edge migrations;
5. no edits from the pingora-gateway writer to .github source/refs/PR state — this issue is the owner-path handoff only.

Downstream pingora-gateway continues to own reusable Ingress/Edge Routing/TLS/HTTP Policy/Load Balancing/Observability/Admin Config/Runtime Isolation semantics and must not absorb product auth/business/identity authority.

[seonghobae]

Single-writer coordination update from the Pingora owner lane, 2026-09-06 KST: do not start a competing .github source branch for this issue while #1946 is active. Fresh changed-file inventory for #1946 shows it already owns exactly the same central policy surface needed here: scripts/ci/pingora_edge_policy.py, tests/test_pingora_edge_policy.py, docs/policies/PINGORA_EDGE_POLICY.md, and CHANGELOG.md.

#1946 is a distinct oversized-Contents/Git-Blobs repair, so its semantics do not satisfy #1952 by implication. The safe owner sequence is: finish/reconcile #1946 normally, then have the existing .github writer adopt its exact protected-main result and add #1952's responsibility-profile RED→GREEN without destructive rebase or parallel writes. Preserve #1946's fail-closed oversized-content evidence and add the separate static-only-vs-edge-runtime classification contract; neither finding should be dropped as an overlap conflict.

Current .github/main remains 43024633eba9d96b0456970391360da5a171fbda; the scanner bounded-context finding remains live on that protected head. No .github source/ref/PR state is modified by this Pingora lane.