Cross-principal creative-lookup shape outside the principal-scope guard's scan roots (gam orders, status scheduler, dead queries.py helper)

[KonstantinMirin]

Problem

PR #1430 added a structural guard (tests/unit/test_architecture_creative_lookup_principal_scoped.py) enforcing that buyer-path creative lookups compare principal_id alongside creative_id (the creatives PK is composite (creative_id, tenant_id, principal_id) — tenant-only matching is how the cross-principal FK-500/leak fixed in #1430 arose). The guard's scan roots are src/core/database/repositories/creative.py + src/core/tools/**.

Three sites with the same tenant-only shape sit outside those roots (all present at the #1430 merge-base — pre-existing, not introduced there):

1. src/adapters/gam/managers/orders.py:648-652 — select(DBCreative).where(tenant_id == …, creative_id.in_(package.creative_ids)), no principal filter. The ids are buyer-supplied (PackageRequest.creative_ids), but on the create path they pass the principal-scoped CreativeRepository.get_by_ids gate before the adapter runs — so today this is a defense-in-depth gap, not a live hole.
2. src/services/media_buy_status_scheduler.py:182-185 — tenant-only Creative lookup; the ids come from CreativeAssignment rows already in the DB (server-derived, low risk).
3. src/core/database/queries.py:152-168 (get_creative_with_latest_review) — tenant-only, dead in production (zero callers under src/; only test callers; sits in the test_architecture_no_raw_select.py allowlist). Deletion candidate rather than fix.

Fix

• Widen the guard's scan roots to cover src/adapters/** and src/services/** (or all of src/), with a shrink-only allowlist for the genuinely principal-agnostic sites.
• Principal-scope sites 1–2 (or allowlist with justification where principal context genuinely doesn't exist).
• Delete the dead queries.py helper and its allowlist entry + test-only callers.

Context

Surfaced by the #1430 re-review ("pre-existing — please file separately"), verified against the tree at 0085f3c04. Sibling isolation issue (media_buy, different mechanism): #1318.

[numarasSigmaSoftware]

Site 1 resurfaced in a re-review at f94e72f92 — line reference has drifted, everything else in this issue still holds.

src/adapters/gam/managers/orders.py is now at :725-729 (was :648-652); the shape is unchanged:

select(DBCreative).where(
    DBCreative.tenant_id == tenant_id,
    DBCreative.creative_id.in_(package.creative_ids),
)

Two independent passes flagged it while reviewing #1544's composite-key work, so it will likely keep resurfacing until the guard roots are widened as this issue proposes. Confirming it is still pre-existing: git log -G'creative_id.in_\(package.creative_ids\)' <merge-base>..HEAD -- src/adapters/gam/managers/orders.py returns empty, so #1544 did not touch it.

Worth noting this issue's own mitigation analysis is still accurate and is the reason it stays low-severity: on the create path the ids pass the principal-scoped CreativeRepository.get_by_ids gate before the adapter runs, and this particular read pulls creative dimensions (width/height), not approval state — so it is defense-in-depth, not a live leak.

Adjacent data point for the "widen the guard roots" fix: #1544 added tests/unit/test_architecture_creative_lookup_principal_scoped.py with _QUERY_ALLOWLIST / _ADMIN_CALL_ALLOWLIST baselines. Widening roots to src/adapters/** + src/services/** would slot into that guard rather than needing a new one.