Cloudflare Cron Trigger wake scheduling for hosted AMS containers

[JSONbored]

Problem

AMS has no webhook receiver — it's a CLI/batch tool whose closest thing to "always on" is the self-scheduling `loop` subcommand, or cron/systemd-timer-invoked one-shot `discover`/`manage poll` runs (confirmed via direct code read: no HTTP listener anywhere in `bin/loopover-miner.js`). Hosted AMS containers need something to wake them on the right cadence, since nothing pushes events to them the way GitHub webhooks push to ORB.

Area

The shared control-plane service (#7173).

Proposal

A Cloudflare Cron Trigger fires on a per-tenant schedule, wakes that tenant's (sleeping, zero-cost) container, and runs one `discover`/`attempt`/`manage poll` cycle before letting it sleep again — mirroring AMS's own documented unattended-scheduling pattern (`packages/loopover-miner/docs/unattended-scheduling.md`), just centrally orchestrated instead of operator-run cron/systemd. This is cheaper to operate than ORB's model, since an AMS container never needs to stay warm waiting for an event.

Deliverables

• Per-tenant cron schedule configuration
• Wake + run-one-cycle + sleep, using AMS's existing one-shot subcommands unmodified
• Exit-code alerting contract (0=success, 2=failure) surfaced to the control-plane's health aggregation (Add a minimal HTTP health endpoint to hosted AMS containers #7177)

Boundaries

• Depends on the provisioning core existing so there's a real container to wake.
• Does not touch AMS's own CLI/subcommand code — this only decides when to invoke it.

Links & Resources

• Design: shared hosting control-plane for ORB + AMS SaaS (provisioning, secrets, billing, health) #7173 (parent — shared hosting control-plane)
• packages/loopover-miner/docs/unattended-scheduling.md — the pattern this mirrors
• Add a minimal HTTP health endpoint to hosted AMS containers #7177 — the health endpoint this reports through

[linear-code]

JSO-4939