fix(slack/run-audit): set onDemand bypass and align entitlement to siteEnrollment

[tathagat2241]

Summary

run audit is an explicit, one-off Slack command — it should run regardless
of whether the site appears in the handler's enabled-list, and without
mutating that list. Today, even after the audit-worker enabled-list gate is
removed (companion PR), api-service still has two issues that prevent the
end-to-end fix:

1. The prerender CSV path still pre-checks isHandlerEnabledForSite and
   short-circuits with :x: Will not audit site '<url>' because audits of type '<type>' are disabled for this site..
2. The entitlement check uses tierResult.entitlement (org-level), while
   the audit-worker downstream gate (checkProductCodeEntitlements) checks
   tierResult.siteEnrollment (site-level). A site can pass the
   api-service check and then be silently dropped in audit-worker, producing
   a confusing user experience.
   This PR fixes both issues and emits the onDemand: true flag in the SQS
   message so the audit-worker bypasses its enabled-list gate.

What changed

• src/support/slack/commands/run-audit.js
  • Pass auditContext: { onDemand: true } to every triggerAuditForSite
    call emitted by run-audit — single audit, audit:all, and the
    prerender CSV path.
  • Drop the redundant configuration.isHandlerEnabledForSite precheck from
    the prerender CSV path so it behaves consistently with the single-audit
    path.
  • Switch entitlement check from tierResult.entitlement →
    tierResult.siteEnrollment in both runAuditForSite and
    runPrerenderAuditForUrls. This matches the audit-worker's downstream
    gate and avoids the previously silent failure when org-level
    entitlement existed but the specific site was not enrolled.
• test/support/slack/commands/run-audit.test.js
  • Updated existing positive-path mocks from entitlement →
    siteEnrollment.
  • Replaced the obsolete "blocks prerender CSV audits when the prerender
    handler is disabled" test with a positive test that verifies the run
    proceeds via the onDemand bypass.
  • New assertions that the SQS payload's auditContext contains
    onDemand: true for single, audit:all, and prerender flows.
  • New regression test: org has entitlement but no siteEnrollment ⇒
    audit is blocked (parity with audit-worker).

Behavior matrix after this PR

Path	Enabled-list check (api-service)	Entitlement key checked	Sets onDemand
Slack run audit	❌ (removed; bypassed downstream)	siteEnrollment	✅
Slack run audit (CSV prerender)	❌ (removed; bypassed downstream)	siteEnrollment	✅
Slack add site / add repo	✅ (pre-filter)	n/a (delegated)	❌
Scheduled trigger (triggerFromData)	✅ (pre-filter via Configuration)	n/a (delegated)	❌

Test plan

• npm test — 11298 passing, 0 failing.
• npm run lint clean.
• Manual verification in stage with the companion audit-worker PR
  deployed:
  • @spacecat run audit <site-not-in-enabled-list> for an entitled site →
    audit runs to completion; the site is not added to any
    enabled/disabled list.
  • @spacecat run audit <site> for an unentitled site →
    :x: Will not audit site '<url>' because site is not entitled for this audit.
  • Scheduled audit for the same not-in-enabled-list site → still skips
    (unchanged).

Risk

• Low, contingent on the companion audit-worker PR being deployed first or
  at the same time. If api-service is deployed alone, the onDemand flag
  is simply ignored downstream and behavior is identical to today (the
  enabled-list check still runs in audit-worker for sites in the list, and
  one-off runs still fail for sites that are not — i.e. no regression, just
  no fix yet).
• The entitlement → siteEnrollment change tightens the api-service
  precheck. Any site that previously passed via org-level entitlement but
  had no site enrollment was already failing silently downstream, so this
  only changes where the rejection happens (api-service now returns a
  clear Slack message instead of a silent worker skip).

Notes for reviewers

• Scheduled audit triggers (src/controllers/trigger/common/trigger.js)
  remain unchanged and still pre-filter by isHandlerEnabledForSite. They
  do not set onDemand, so the audit-worker bypass does not apply to them.
• triggerAuditForSite in src/support/utils.js already accepts and
  forwards an auditContext, so no signature change was needed there.

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 PR: adobe/spacecat-audit-worker#2599

Related Issues

Thanks for contributing!

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

[github-actions]

This PR will trigger a patch release when merged.