feat(managementapi): wire the listing filter seams part 4/4 (S09 Enforcement plan: 19/20)

Part 4 of 4 of the S09 enforcement plan — Step 19: Permission-filtered repository listing.

The step is split into 4 stacked MRs to keep each within the review size limit (≈800 ideal). Each part targets the previous one; the stack sits on step 18 part 4 (!2146 (merged)). Review and merge bottom-up.

Stacked MRs (review/merge bottom-up)

• feat(authz): probe verdicts and listing-filter ... (!2251 - merged) • David Fernandez • 19.4
• feat(managementapi): probe-dispatched listing b... (!2252 - merged) • David Fernandez • 19.4
• test(managementapi): filtered listing behavior ... (!2253 - merged) • David Fernandez • 19.4
• feat(managementapi): wire the listing filter se... (!2254 - merged) • David Fernandez • 19.4 👈

This part (~380 reviewable LoC)

The production wiring, replacing part 2's interim placeholders:

• wireManagementAPI takes a managementListingSeams struct (named fields, so the two resolver slots cannot be positionally swapped).
• The pre-cache IAM client gets the distinct uncachedIAMClient type, making the cached-for-uncached swap a compile error rather than a silent cache-wipe hazard: a listing chunk reads ~10,000 near-unique objects, and the point-check CachingResolver clears its whole map at 10,000 entries. TestWireIAM_UncachedClientIsThePreCacheInstance pins the construction.
• The composition-root glazClient interface widens to embed glaz.BatchChecker (the concrete client already implements it).
• With IAM or GLAZ unconfigured, the listing seams get fail-closed placeholders that error (503) rather than answering an empty success — unreachable while the allow-all evaluator is wired, loud if that ever changes.

Tests: the wiring unit tests (gate behavior, placeholder fail-closed contracts) and a DB-backed integration case (TestIntegration_WireManagementAPI_ListingFilterUsesWiredSeams) proving through real wiring and Postgres that a repository-scoped principal receives exactly their repository and a grantless principal receives an empty 200.

This is the only part touching database-backed tests; the step carries no migrations and no schema change.

References

• Plan: docs/plans/2026-08-21-s09-authorization-enforcement.md
• Spec: S09 (authorization), Repository listing

No e2e scenario is added or affected: no catalog covers the management API, and the listing filter's behavior is pinned by the step's handler tests (plan Testing Strategy).

Related to #861 (closed)