feat(cli): add StatusPageV3, StatusPageV3Component and StatusPageV3AutomationRule constructs [RED-00]

[tnolet]

Affected Components

• CLI
• Test
• Docs

None AI notes

I tested this locally and it all seems to work as described: the constructs, the import / export / codegen etc.
This can live next to current status pages till we actively deprecate them. Backend and frontend have already been pushed.

Notes for the Reviewer

Monitoring-as-code for v3 (components-based) status pages. Backend side: checkly/monorepo#3846 (mapping tables, merged) and checkly/monorepo#3852 (resource types, node classes, public API).

Three constructs, exported from checkly/constructs:

• StatusPageV3 — same status-page type key as StatusPage, discriminated by version: 3 in the payload (the CheckGroupV2 precedent). No cards; carries the v3 page settings (description, logoDark, privacyPolicyLink, termsOfServiceLink, footerText, googleAnalyticsTag, allowIndexing). StatusPageV3.fromId() lets components/rules attach to a page created in the UI.
• StatusPageV3Component (status-page-component) — { statusPage, type: 'SERVICE' | 'GROUP', name, description?, hidden?, displayOrder, parent? }. The component points at its page (the backend needs the page first; the deploy DAG resolves the ref). Validation: parent must be a GROUP on the same page.
• StatusPageV3AutomationRule (status-page-automation-rule) — tags-scoped rule opening one incident on the listed components; coolDownMinutes maps to the backend's coolDownWindowMinutes. Validation: at least one tag, no OPERATIONAL impact, components on the same page.

Registered in Resources/Project.data, the deploy payload order (services, pages, components, rules, …), the deploy pretty-names, and the AI-context reference (example inlined). A logical id deployed as StatusPage cannot be redeployed as StatusPageV3 — the backend rejects it with a clear message rather than silently switching generations.

Deliberately not in this PR: construct-codegen / import plan support for the three types (the backend import plan does not emit them yet, so nothing breaks), which is why the reference example is hand-written instead of generated into gen/.

Testing

• src/constructs/__tests__/status-page-v3.spec.ts: synthesized payloads (version: 3, { ref } values, coolDownWindowMinutes), duplicate-logicalId diagnostic, fromId() UUID validation, parent-not-a-GROUP / other-page / empty-tags diagnostics.
• pnpm run test:types, eslint and tsc clean; prepare:ai-context runs.
• Deployed end to end against the monorepo branch via the backend's route-deploy-status-pages-v3 integration spec (same payload the constructs synthesize).

🤖 Generated with Claude Code

https://claude.ai/code/session_014WTgyksVAQY5jpD2fb3rYL

Import / codegen (added)

checkly import now generates these constructs: StatusPageCodegen dispatches on the payload version to a new StatusPageV3Codegen; components and automation rules have their own codegens and importable resource types (status-page-component, status-page-automation-rule), with page/parent references resolved to imported variables, friend exports, or fromId(). Backend side (import plan emitting v3 pages, components and rules, with single-page cascade): checkly/monorepo#3893.

[sorccu]

I might have missed this during a quick scroll through so sorry if already covered but: Could you add the @deprecated jsdoc to the old resource types? You could also potentially add a validation warning when the old resource is used. If you want to do that, take a look at check groups for an example of how it can be done.

Also, Windows tests are failing and it looks like a real failure, though it seems odd. Re-run to confirm it's not flaky, and if it remains fix the tests please.

[tnolet]

Will do later today. Hopefully tomorrow we can merge it