test(managementapi): the container upstream association integration walk part 15/15 (S17 Phase 6 plan: 42/42)
Why
Parts 12 to 14 drive the handlers against a fake, which proves a mapping holds against a fake wired to agree with it. This walk runs the same routes against Postgres, where the store's real sentinels reach the handler.
The stack
Fifteen parts, each stacked on the last, each green on its own, reviewed in this order. Each part stays under 700 changed lines, counted as insertions plus deletions against the part it targets, except part 13 at 891, which carries part 12's review-driven dedup.
The delete guard in part 9 must be deployed before part 11's associate route serves traffic. Merge order alone does not close the window: within one rollout, a pod without the guard can answer 202 on destructive=true for an upstream that a new pod has just associated, leaving a tombstone the reaper refuses.
530 changed lines against guardrail 18's 500 ceiling (526 in the walk, 4 in a read_handlers_integration_test.go comment): this part is one coherent test group, and splitting it further would separate cases that share a rig and a fixture.
For guardrail 12, this part adds no e2e scenario, because part 14 added the container association rows to the catalogs. For guardrail 24, it changes no customer-visible surface, so docs/user/ needs no update.
Related to #314 (closed)