test(managementapi): cover the container upstream reads and associate part 12/15 (S17 Phase 6 plan: 42/42)
Why
Part 11 registered the routes with the contract, binding, and wiring tests that prove they are served and bound. Only its list tests exercise a handler's behaviour, so the rest of the dispatch and the rendering is unproven until this suite runs it.
It also mirrors the Maven list-verdict tests that part 11's list tests leave open: the empty list opted in, an unavailable or abandoned evaluator, an unusable verdict batch, and a repeated include_permissions value, which joins part 11's malformed table.
The summary's per-upstream read_repository gate landed first, in feat(managementapi): serve upstream visibility,... (!2959 - merged) • Hayley Swimelar • 19.5, so this part's rig gives its caller read_repository on every upstream. A new case pins the associate's 201 for a caller who reads none of them.
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.
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.
698 changed lines against guardrail 18's 500 ceiling: this part is one coherent test group, and splitting it further would separate cases that share a rig and a fixture.
This test-only part adds no e2e scenario (guardrail 12): the docker and oci upstream scenarios, list-verdicts included, land in part 14, test(managementapi): cover the container upstre... (!2859 - merged) • Hayley Swimelar • 19.5. It changes no customer-visible surface, so no docs/user page moves (guardrail 24).
Related to #314 (closed)