feat(llmo): register recurring DRS prompt-suggestion schedules at onboarding

[dzehnder]

Summary

Phase 3 of the DRS prompt-suggestion schedules + onboarding-triggers effort (local/drs-prompt-suggestions-schedules-onboarding-plan.md). Wires three new onboarding triggers into the V2 onboarding path so newly onboarded LLMO sites get a recurring DRS schedule (plus an immediate first run) for each prompt-suggestion pipeline.

New helpers next to triggerBrandalfOnboardingJob in src/controllers/llmo/llmo-onboarding.js, each guarded by drsClient.isConfigured():

Helper	provider_id	Cadence
triggerSemrushPromptJob	prompt_generation_semrush	twice_monthly
triggerCitationAttemptJob	prompt_generation_agentic_traffic	twice_monthly
triggerSyntheticPersonasJob	prompt_generation_synthetic_personas	quarterly

• prompt_generation_agentic_traffic is the provider behind "Citation Attempts" (no standalone citation-attempt provider — the name won't grep, so there's a code comment).
• Each uses a single drsClient.createSchedule({ ..., triggerImmediately: true }) (no separate submitJob + createSchedule).
• Invoked from the V2 block after the Brandalf trigger (which chains base prompt generation on completion, LLMO-4258) — not fired in parallel before brand data exists (plan Phase 0.3). The immediate run is best-effort; the durable outcome is the recurring schedule row.
• enableBrandPresence defaults false (plan Phase 0.4).

Error handling — split semantics

• Immediate first run: best-effort. If it produces nothing (e.g. brand/base-prompt data not present yet) the next scheduled run self-heals.
• createSchedule (schedule registration): NOT best-effort. A failure means the site never gets a recurring schedule and nothing self-heals, so it is logged at ERROR with site_id + provider_id + status and surfaced via say/ops — never silently swallowed. Onboarding still succeeds (mirrors the brand-activation side-effect handling in brands.js activateBrand, which logs full context before we mirrored it).

Cross-repo dependency (deploy ordering)

Depends on a new additive createSchedule(...) method in @adobe/spacecat-shared-drs-client (separate spacecat-shared PR, not yet released). This PR bumps the dependency to 1.14.0.

This PR must merge/release after the shared drs-client createSchedule PR is published as 1.14.0. Until then, a fresh npm ci / bundle build cannot resolve 1.14.0 and CI install will be red — this is the intended cross-repo sequencing, not a defect. Unit tests do not hard-depend on the real method: they mock the DRS client (as existing onboarding tests do).

Confirmed createSchedule signature (from the shared PR author)

drsClient.createSchedule({
  siteId,                       // required, string
  providerIds,                  // required, string[] non-empty (one element per single-provider pipeline)
  cadence,                      // required, SCHEDULE_CADENCES value: 'twice_monthly' | 'quarterly'
  description,                  // optional, length-capped (1024)
  enableBrandPresence = false,
  providerParameters,           // optional per-provider passthrough
  priority = 'HIGH',            // 'HIGH' | 'LOW'
  metadata,                     // optional
  triggerImmediately = false,
  timeout,                      // optional ms
}) // => Promise<{ scheduleId: string, alreadyExisted: boolean }>  (409 dedup => alreadyExisted:true)

Key contract points this PR honors:

• providerIds is an array (the job_config.provider_ids envelope), so each helper passes a one-element array.
• cadence enum values use underscores (twice_monthly / quarterly); the client derives the cron server-side (frequency:'cron', per-site hour jitter for twice_monthly) — callers cannot pass raw cron. Kept as local literals matching SCHEDULE_CADENCES so the module loads against the currently-installed client; can be swapped for the imported const once 1.14.0 is installed.
• No orgId/imsOrgId params — DRS derives the tenant-isolation key from site_id server-side and rejects any caller-supplied imsOrgId (at any nesting/case). This PR deliberately does not thread imsOrgId into createSchedule.

Tests

test/controllers/llmo/llmo-onboarding.test.js (mock DRS client; no real createSchedule dependency):

• each helper registers the correct providerIds (array) + cadence with triggerImmediately: true, enableBrandPresence: false, and no imsOrgId/orgId;
• each helper is a no-op (no createSchedule) when isConfigured() is false;
• a createSchedule failure propagates to the caller (not swallowed at the helper);
• V2 activateBrandAndGeneratePrompts registers all three schedules after the Brandalf trigger;
• a createSchedule failure is logged at ERROR with site_id + provider_id + status while onboarding still completes.

npm run lint clean. All 11 new tests pass. The full llmo-onboarding.test.js file is 142 passing / 1 failing, where the single failure is a pre-existing settleWithin "before all" hook timeout that also fails on clean main (environment-related, unrelated to this change).

🤖 Generated with Claude Code

[github-actions]

This PR will trigger a minor release when merged.