Leer accountsIdsByService del Parameter Store con fallback a Secrets Manager

[juanhapes]

Qué

El Invoker resolvía el account id de cada service (para invocar lambdas cross-account) leyendo el secret AccountsIdsByService de Secrets Manager, replicado en ~60 cuentas. Esta PR pasa a leer el Parameter Store accountsIdsByService (único en la cuenta Devops, RAM-shared), armando el ARN arn:aws:ssm:${AWS_REGION}:${DEVOPS_ACCOUNT_ID}:parameter/accountsIdsByService y resolviéndolo con una única llamada GetParameter.

Cambios

• Cambiado SecretFetcher para leer el Parameter Store vía @aws-sdk/client-ssm. La interfaz pública (fetch() / secretValue) queda intacta.
• Fallback a Secrets Manager (con logger.warn) solo cuando falta DEVOPS_ACCOUNT_ID — para services con el plugin viejo durante la transición. Si la env var está presente y el GetParameter falla, no hay fallback (tira JANIS_SECRET_MISSING, no enmascara errores reales).
• Agregado el permiso ssm:GetParameter a invokePermissions sobre arn:aws:ssm:*:*:parameter/accountsIdsByService.
• Agregada la dependencia @aws-sdk/client-ssm.
• Tests: lint + 96 specs en verde.

A tener en cuenta

DEVOPS_ACCOUNT_ID lo inyecta el plugin sls-helper-plugin-janis (ya disponible en el pipeline vía /shared/{env}/ci-cd). El fallback al secret mantiene el comportamiento actual mientras los services adoptan el plugin nuevo.

[juanhapes]

Se descarta este enfoque. En vez de resolver el ARN del parámetro compartido a mano dentro de @janiscommerce/lambda, la lógica de descubrimiento (RAM ListResources list→get + SSM GetParameter) y el cacheo en memoria se encapsulan en un package npm dedicado y reutilizable. @janiscommerce/lambda lo consumirá en un PR nuevo. Cierro; el diff queda como referencia.