fix: sites resolve PLG gating

[Sugandhgyl]

Please ensure your pull request adheres to the following guidelines:

• make sure to link the related issues in this description. Or if there's no issue created, make sure you
  describe here the problem you're solving.
• when merging / squashing, make sure the fixed issue references are visible in the commits, for easy compilation of release notes

If the PR is changing the API specification:

• make sure you add a "Not implemented yet" note the endpoint description, if the implementation is not ready
  yet. Ideally, return a 501 status code with a message explaining the feature is not implemented yet.
• make sure you add at least one example of the request and response.

If the PR is changing the API implementation or an entity exposed through the API:

• make sure you update the API specification and the examples to reflect the changes.

If the PR is introducing a new audit type:

• make sure you update the API specification with the type, schema of the audit result and an example

Related Issues

Thanks for contributing!

[Kanishkavijay39]

Missing integration tests in test/it/

CLAUDE.md requires IT tests for modified endpoints. No new cases were added to test/it/ for the structured 404 responses or the internal-caller remap. The existing unit tests stub findByImsOrgId entirely, so a model-method rename,
column-mapping change, or DTO drift would silently break this feature. Add at minimum: external caller + no entitlement, external caller + PRE_ONBOARD tier, and internal caller + no entitlement remapped to site_not_enrolled.

No test for Organization.findByImsOrgId throwing

All 13 new test cases stub findByImsOrgId to resolve. None reject. Combined with issue 2, this is the highest-risk untested branch. Add a case where findByImsOrgId rejects and assert the response matches the expected badRequest('Failed to
resolve site') shape (not an unhandled 500).

callerImsOrg trust model should be documented

The parameter is read from the query string with no server-side check that the caller actually belongs to that IMS org. A client can pass any internal org's IMS ID and get the "internal" response shape. The security impact is bounded - the
remap only narrows 404 detail and cannot widen data access (the 200 path is still gated on accessControlUtil.hasAccess(organization) for the requested org). But this trust assumption should be documented. Either: (a) add a note in the OpenAPI
description that this param is a UX hint only and not an authorization signal, or (b) consider deriving callerIsInternal from the authenticated principal if the caller's IMS org is available in context.auth. Also add a test confirming that a
spoofed callerImsOrg does not change any 200-OK response.

resolveFailure helper naming invites misuse

src/controllers/sites.js:1200-1204 - The OpenAPI spec says generic 404s omit resolveStatus and details, but the helper always includes both. If a future maintainer reaches for this helper for a generic not-found case, the contract silently
breaks. Rename to resolveStatusFailure to make scope explicit, or have it omit undefined fields.

Minor (Nice to Have)

• src/controllers/sites.js:1252, 1262 - The remap branch log.info lines fire in production on every internal-caller remap. Downgrade to log.debug once the feature is confirmed working.
• src/controllers/sites.js:1213, 1215 - Log callerImsOrg via a structured object rather than string interpolation to avoid CRLF log injection: log.info('[resolveSite] caller resolved', { callerImsOrg, callerIsInternal }).
• src/support/utils.js:1944 - The orphan @returns {Array} JSDoc line above the new helpers looks like it belonged to the function below. Delete or reposition.
• docs/openapi/sites-api.yaml:302-309 - The description exposes internal implementation details (ASO_PLG_EXCLUDED_ORGS, "Spacecat UUID"). Trim to the client-facing behavior: "IMS Org of the calling shell. Used by internal Adobe surfaces to
  suppress the PLG onboarding wizard for demo/internal orgs. External callers can omit."
• src/controllers/sites.js - The aso_pre_onboard status value is product-prefixed in an otherwise product-agnostic discriminator set. pre_onboard with the product code in details.productCode would avoid a parallel llmo_pre_onboard appearing
  when the next product reuses this endpoint. Cheaper to change now than after UI clients ship against the string.
• test/controllers/sites.test.js - Add a test for callerImsOrg: '' confirming it behaves identically to omitting the param.
• test/controllers/sites.test.js - Add a test for accessControlUtil.hasAccess(organization) returning false to confirm the response is the generic 404 with no details.

[solaris007]

🎉 This PR is included in version 1.476.2 🎉

The release is available on GitHub release

Your semantic-release bot 📦🚀