fix(federation): relay FM's 409 when a partner already has an agreement

Sergio Gimenezrequested to merge
fix/relay-agreement-exists into develop 
sequenceDiagram
  participant P as portal
  participant OEG
  participant FM
  P->>OEG: POST /platform/v1/federation/agreements (partner already has one)
  OEG->>FM: POST /internal/agreements
  FM-->>OEG: 409 agreement-exists, "Edit agreement {id} instead."
  Note over OEG: before: 409 not in FM's contract for this route, so 502<br/>now: relayed as is
  OEG-->>P: 409 + FM's ProblemDetails

FM is moving to one agreement per partner, edited in place (FM MR feat/one-agreement-per-partner, spec in architecture !15 (merged)). A second POST /agreements, or a PATCH that would make an expired agreement live next to the partner's current one, answers 409 agreement-exists. This relay listed no 409 for either route and turned it into a 502.

Two lines in the status allowlists, plus 409 in the OpenAPI responses of both routes. The PATCH summary changes because any term can now change in place. The body is still forwarded byte-for-byte, so the wider PATCH (zones, terms, API types, mappings) needs nothing else here.

Result
unit tests 1266 passed, 1 skipped; mypy, ruff clean
tests changed 409 joins the relayed FM errors; the "outside the contract" case now uses 403
testbed, ns oop, OP-1 → OEG → FM second agreement: 409 agreement-exists "Edit agreement 1a4d2b51… instead"; reviving an expired one next to a live one: 409

Safe to merge before the FM change: until FM sends 409, nothing reaches the new path.

🤖 Generated with Claude Code

Merge request reports