fix(fm): onboard partner apps with capability kind workload

Sergio Gimenezrequested to merge
fix/workload-capability-kind into develop

Every federated deploy failed at the receiving operator. When FM-B onboards a partner's app it creates a service specification at SRM-B, and it still asked for capability kind deploy_workload. SRM renamed that kind to workload (ADR-0056: a capability kind names a capability, not an operation, with no alias for the old name), so SRM-B answered 400 and FM-B returned 500 to the partner's OnboardApplication.

sequenceDiagram
    participant FA as FM-A
    participant FB as FM-B
    participant SB as SRM-B
    FA->>FB: POST /{ctx}/application/onboarding
    FB->>SB: POST /internal/catalog/service-specifications (capability_kind)
    Note over FB,SB: before: deploy_workload, 400, FM-A gets 500<br/>after: workload, 201
    FB-->>FA: 200

The change is the one value in inbound_onboarding.py and the test that pinned it. OEG already sends workload.

Found running the full Release 2 deploy on the two-operator docker harness with auth on (App Provider, OEG-A, SRM-A, command.fm.service.deploy, FM-A, EWBI, FM-B, SRM-B). With this fix every hop completes: OEG-A reports the instance ready and both FMs record install-app completed. Unit tests: 310 pass.

Not fixed here, and not FM's: SRM's deploy on refactor/tf-sdk-ports doesn't call TF-SDK yet, so nothing runs on the partner's cluster even though SRM-B reports the order completed. Raised with SRM.

Merge request reports