feat(cloud-manager-client): add CloudManagerApiClient for CM Management API

[rpapani]

What

Adds CloudManagerApiClient to spacecat-shared-cloud-manager-client — a read-only client for the Cloud Manager (SSG) Management API, distinct from the existing git-operations CloudManagerClient (clone/push/pull/PR).

It resolves an AEM CS site's source-code coordinates and IMS org during onboarding:

Method	CM endpoint	Returns
getProductionPipeline(programId)	GET /program/{id}/pipelines	{ repositoryId, branch } (CI_CD + STAGE_PROD, else PROD; BUILD phase)
getRepository(programId, repositoryId)	GET /program/{id}/repository/{id}	{ url, type }
getProgram(programId)	GET /program/{id}	{ imsOrgId }
resolveCodeConfig(programId)	(composes the above)	{ owner, repo, type, url, ref } — matches site.code

Why

Onboarding an AEM CS site needs its code config (owner/repo/ref/type), but the publish host publish-p{programId}-e{environmentId}.adobeaemcloud.net encodes only program/environment — not the repo. The only source of truth is the CM Management API. This client is the shared building block; spacecat-api-service will call it from the onboarding flow (follow-up PR) to fill the existing // TODO: Add AEM CS pattern code config resolution in updateCodeConfig.

Part of SITES-40809 (onboard automation for code optimizations).

Auth

OAuth Server-to-Server (grant_type=client_credentials) — the CM API client credentials are exchanged with IMS via ImsClient.getServiceAccessTokenV3() (reused, not hand-rolled). Every request carries Authorization: Bearer <token>, x-api-key (client id), x-gw-ims-org-id.

createFrom(context) reads from context.env: CM_API_CLIENT_ID, CM_API_CLIENT_SECRET, CM_API_SCOPES, CM_API_IMS_ORG_ID, CM_API_BASE, IMS_HOST.

Network dependency (why this is a draft)

The CM Management API is reachable from SpaceCat only over the private *.private.adobe.io endpoint via MCT (SITES-41140). CM_API_BASE selects the per-env private endpoint (https://ssg-stage.private.adobe.io/api dev/stage, https://ssg.private.adobe.io/api prod). This library change has no network dependency itself, but the end-to-end path (and the consuming service) can't be exercised in dev until the MCT CM /32 route lands and the consuming Lambda sits in mct_workload_subnet_ids. Draft until that gate clears so it can be verified together.

Tests

• test/cloud-manager-api-client.test.js — nock-driven, covers auth headers, token exchange, each method's success + error paths, and defaulting. Package coverage remains 100% lines/branches/statements/functions.

[github-actions]

This PR will trigger a minor release when merged.