fix(api): gate partner-wide script writes on canManagePartnerWidePolicies (#3262)

[bdunncompany]

Fixes #3262.

Partner scope was standing in for the partner-wide capability. canManagePartnerWidePolicies appeared nowhere in scripts.ts, and its doc comment names this exact substitution as the thing it exists to prevent.

Four sites, not one

Your issue names the create path and asks for update/delete too. Building it surfaced a fourth that isn't in the issue — and it's the one I'd most expect to be missed:

#	Vector	Prior guard	Gap
1	Create with availability: 'partner'	auth.scope === 'partner'	the reported vector
2	Widen an org script to partner-wide on edit	resolveRescopeTarget checked scope only	a second creation vector for the same privilege
3	Edit an existing partner-wide script	blocked only auth.scope === 'organization'	a partner selected user could rewrite code already running as SYSTEM everywhere
4	Delete an existing partner-wide script	same guard, same gap	removes automation from every org under the partner

Sites 3 and 4 already had a partner-wide guard — it just tested the wrong thing. It kept org-scoped users out and let every partner-scoped user through regardless of org_access.

Site 2 is the one worth a second look on review: availability: 'partner' on PUT /:id reaches partner-wide state without ever touching the create handler, so gating create alone would have left the privilege fully reachable.

Implementation

Follows peripheralControl.ts:508 verbatim — PARTNER_WIDE_WRITE_DENIED_MESSAGE with 403 — matching the nine other routes you listed as doing it correctly.

RescopeAuth gains partnerOrgAccess (the capability is deliberately not derivable from accessibleOrgIds, so it has to be carried) and its scope narrows from string to AuthContext['scope'] so the capability check typechecks.

Tests, and the control that mattered

Five: four denials — create, widen, edit, delete as a partner user with partnerOrgAccess: 'selected' — plus a positive control proving a full-partner admin can still widen, so the denials can't pass on a handler that simply rejects every partner write.

The two existing partner-auth helpers now default to partnerOrgAccess: 'all'. That is the user those positive cases always meant to describe; without it the gate would have failed pre-existing tests, which is itself a small signal the fixture was under-specified.

All five were run against the un-fixed code. My first control attempt was wrong and worth flagging: I neutered the guards with a regex that matched only two of the four call sites — the edit/delete guards use a different expression shape — so only two denials failed and I would have shipped two unproven tests. Neutering canManagePartnerWidePolicies itself to return true gives the honest result:

× create as 'selected'   FAIL
× widen  as 'selected'   FAIL
× edit   as 'selected'   FAIL
× delete as 'selected'   FAIL
✓ widen  as 'all'        PASS   (control still passes)

Gate

tsc --noEmit exit 0 · vitest run 1285 files / 20525 tests / 0 failures · eslint clean on both changed files.

Left out deliberately

Your point 3 — auditing existing orgId IS NULL AND partner_id IS NOT NULL scripts for any created by a selected-access user — is a query against your deployment rather than a code change, so it isn't in this diff.

[ToddHebebrand]

Thanks @bdunncompany — solid work catching the fourth vector (widen-via-rescope) that the issue didn't name. CI was green and a high-effort review confirmed the gating logic is correct across all four paths.

I pushed one maintainer commit (1cfe0e8) on top with two defense-in-depth hardenings the review flagged, so the whole fix lands atomically:

• Same-partner ownership check in the app layer. The new PUT/DELETE guards checked the capability but relied on RLS row-invisibility alone for cross-partner containment. There's no exploit today, but any future refactor that loads scripts under a system DB context (the [api] Mass agent reconnect can poison the Postgres pool (idle-in-transaction timeouts on config_policy_assignments) → heartbeat 500s + login outage #1105 pattern) would have turned that into cross-tenant write/delete. The guard now returns 404 (not a leaky 403) when script.partnerId !== auth.partnerId — one pre-existing rescope test updated accordingly since the ownership guard now fires first.
• RescopeAuth.partnerOrgAccess is now a required key so future callers can't omit it and silently compile into fail-closed 403s for genuine full-partner admins.
• Both route guards now share one partnerWideScriptWriteError helper so PUT and DELETE can't drift.

Will merge once CI is green on the new commit.