sec(auth): enforce per-permission Constraints on ladder/config/RI-exchange-config/marketplace/revoke (SEC-01 follow-up to #60)

[cristim]

Problem

Issue #60 fixed the SEC-01 fail-open class (a bare HasPermissionAPI verb
check with no per-permission Constraints evaluation) on execute-any/
execute-own (direct-execute), approve-any/approve-own (session approve
AND the approveViaToken email deep-link flow), and runPlannedPurchase.

Issue #60's own review comments widened the census beyond those three named
verbs to a full sweep of requirePermissionConstraints call sites in
internal/api. Two more sites were fixed alongside #60 (approveViaToken's
own defense-in-depth check). Five sites from that wider census remain
unfixed:

Handler	Where
upsertLadderConfig	internal/api/handler_ladder.go (~line 77 as of the review)
updateConfig	internal/api/handler_config.go (~line 59)
updateRIExchangeConfig	internal/api/handler_ri_exchange.go (~line 963)
marketplaceList	internal/api/handler_marketplace.go (~line 139)
revokePurchase	internal/api/handler_purchases_revoke.go (~line 139)

Line numbers are from the 2026-07-28 review pass and may be stale; re-locate
each handler on current origin/main before fixing.

marketplaceList and revokePurchase move money in the seller/refund
direction, where MaxPurchaseAmount may not be the relevant constraint but
Providers/AccountIDs/Services are -- the fix for each site should use
whichever Constraints dimensions actually apply to that verb, not
mechanically copy purchaseConstraintSets.

Note on the two independent gates

getAllowedAccounts (session/group scope) and requirePermissionConstraints
(per-permission Constraints) are independent gates. A permission with no
AccountIDs constraint satisfies the second unconditionally, so passing
requirePermissionConstraints is not evidence that account scoping also
happened, and vice versa. Verify both gates independently for each of the
five sites above.

Fix direction

For each handler: build the constraint set(s) from whichever data the verb
actually mutates (mirroring purchaseConstraintSets's approach of deriving
from store/persisted data, never client-supplied numbers), and call
requirePermissionConstraints(ctx, session, action, resource, sets) (the
action parameter was added in #60; thread the real verb for each site
through it). Add a regression test per site mirroring
TestHandler_executePurchase_PermissionConstraintsDenied: a session that
passes the bare verb gate but whose Constraints reject the request must
get 403 before any state mutation.

Triage

type/security, priority/p1, severity/high, impact/all-users,
effort/m, triaged -- same fail-open class as #60 on the same
Constraints struct.

[cristim]

Config portion merged in #456 at ac96148bf0c1ef8630aa16dc1d483b1092b69f7e. The merged tree exactly matches independently approved d1f27a6 (tree 7abaad02cd1d3add4fbc3fb713b675c26b06a081).

Fresh local checks on the actual merged tree passed with Go 1.26.6 and the race detector: production HTTP/router/auth/PostgreSQL config matrix 5.080s, strict matcher 3.728s, and infrastructure-key HTTP/router/PostgreSQL fixture 3.821s. Scoped denials preserve stored state; allowed writes persist. PostgreSQL 17 used fresh databases with only the testcontainers bootstrap substituted. The infrastructure credential and transport are fixtures; no cloud SDK or secret-loading behavior is claimed. This is local merged-code verification, not a deployed-environment mutation test.

Keep this issue open. Marketplace list/cancel enforcement is the next dependent slice, followed by scheduled/completed revoke and Azure refund quote enforcement. The mark-only email revoke workflow remains outside this issue's named handler scope.

[cristim]

Marketplace part merged in PR #460, commit 6d9a70f614afd72ded5b17d4bd3bae6960695077.

Verified the five changed files are identical to independently approved a3ec6f6c7ed2858403ce52500cebc3bfb0f0b3f1. Fresh verification on the actual merged checkout passed with Go 1.26.6 and race enabled in 6.552s: real HTTP through the router, real auth.Service, full PostgreSQL migrations and a fresh local database, plus effective-action/error controls. Authorized list/cancel requests persisted their transitions; denied requests left stored rows unchanged and invoked no provider factory.

HTTP transport, cached AWS configuration and EC2 are fixtures. This verifies local merged behavior; no production cloud transaction or deployment was performed. Root tracks main CI/deployment separately.

Keep #404 open. Scheduled/history revoke and Azure refund quote remain required in the final dependent part; implementation is underway with its own baseline, independent review and committed-SHA verification gates.