feat(worker): TCP and SSL certificate-expiry checks

[amondnet]

Context / Motivation

TCP and SSL certificate-expiry checks are declared in the README roadmap, and the config schema already accepts tcp and ssl as check kinds — but packages/core/src/check.ts:38 intentionally falls through to the HTTP path for both. A user who writes kind: tcp today silently gets an HTTP check.

This is table stakes against the alternatives:

• Uptime Kuma and Gatus both ship TCP checks and certificate-expiry monitoring; Gatus exposes certificate expiration directly as a condition in its README examples.
• upptime has recurring, unmet demand for TCP/IPv6 checks (tcp-ping fails with IPv6-only endpoint upptime/upptime#999, Failed to tcp-ping on IPv6-only host upptime/upptime#976).

The Cloudflare platform makes this feasible at the edge: Workers' connect() TCP sockets cover the TCP check, and certificate expiry can be read by inspecting the TLS handshake.

Proposed scope

• Implement a real TCP check via Workers connect() — connect success/failure and connect latency.
• Implement an SSL check that inspects the certificate and reports days-to-expiry, with a configurable expiry threshold that drives degraded before down.
• Remove the HTTP fall-through in packages/core/src/check.ts for these kinds.
• Record results through the existing check/history/status pipeline so they behave like HTTP checks.

Acceptance criteria

• kind: tcp performs an actual TCP connection and yields a real status and latency.
• kind: ssl reports certificate expiry and flags an approaching expiry per the configured threshold.
• Both kinds produce history bars and status on the page, identical in behaviour to HTTP checks.
• Connection failures and timeouts map to sensible statuses rather than errors.

Priority / Effort / Dependencies

• Priority: p2
• Effort: M (1–3 days)
• Dependencies: none. Related to the alert condition DSL (certificate expiry is a natural condition input).