answer GetFederationDetails as the partner

Part of #23.

Two FMs can't read each other's federation details. FM serves only DELETE on /{federationContextId}/partner, so when a partner sends the GET, FastAPI answers 405 and our own FM relays that back to the operator. An OEG → FM-A → FM-B run caught it; REQ-FED-12 lists GetFederationDetails among the operations FM implements.

FM now answers with what it actually knows about itself: its network codes (FM_MCC / FM_MNCS) and platformCaps, the same value inbound CreateFederation already returns.

Offered zones and the edge-discovery and LCM endpoints are left out of the JSON rather than sent as null or []. FM has no zone catalogue or endpoint configuration yet, OPG.04 marks none of those fields nullable, and an empty zone array would break its minimum-of-one rule.

A terminated context, an unknown context, one belonging to another partner, and our own outbound context all return a GSMA-format 404.

Checks: 234 passed, 1 skipped (the FM↔️SRM test, which needs SRM running). mypy, ruff and import contracts clean. In the two-FM e2e the call that returned 405 now returns {"platformCaps":["serviceAPIs"],"allowedMobileNetworkIds":{"mcc":"214","mncs":["07","01"]}}.

Still open in #23: the zone operations (GetZoneData and friends), which need shared_resource_catalogues.