External dependency monitoring (generic queries, external providers)

## Is your feature request related to a problem? Please describe.

A lot of services people may want to monitor sit on top of third-party services and/or depend on upstream providers we don't control: AWS regions, Cloudflare, GitHub, a payment provider, and so on.

We're currently evaluating status pages and today, if we want those upstream dependencies to show up alongside our own services, we have to either embed the Peekaping status page inside a larger external status page (two visual languages, two sources of truth) or run a separate tool. It would be much nicer to render everything from Peekaping so the status page is one coherent thing, including the upstreams our services depend on.

## Describe the solution you'd like

- Treat external/upstream status as first-class monitors, implemented as new executor types, so they reuse
everything downstream (status pages, heartbeat history, uptime %, notifications, our /metrics exporter PR). - From a look at the code this fits cleanly: `executor.Executor` (Execute/Validate/Unmarshal) is already the point where new plugins cold be introduced, and each type would produce a `Result{Status, Message, ...}`.

Two layers:

1. Generic, configurable check types not tied to a specific vendor:
- Prometheus/PromQL query with configurable thresholds (for reflecting your own existing Prometheus alerts onto a Peekaping status page)
- numeric result with thresholds (e.g. latency in ms, with warn/crit bands)
- regex over a response body mapping to up / down / maintenance (/ degraded (see below))
2. Named provider integrations for services with a defined status API (AWS, GCP, Azure, etc.). Architected as a thin "fetch" (provider-specific) feeding a shared "map" layer (the thresholds/regex/enum-mapping from layer 1), so providers stay small and the mapping logic is reused.

A big multiplier: a large share of popular status pages are Atlassian Statuspage and share the same `/api/v2/summary.json` schema (GitHub, Cloudflare, Discord, Reddit, Twilio, Datadog, and many more). So one Statuspage adapter plus a catalog of `{name, url, component}` covers most of the list, and that catalog can be a data file (no recompile to add one). Only the bespoke formats (AWS/GCP/Azure) need their own parser, registered at compile time like the existing executors. Adding a provider stays close to "add a file."

### Degraded / partial-outage status

The main open question for the above. Upstream feeds care a lot about "degraded" / "partial outage", but Peekaping's status is currently 4-state (down/up/pending/maintenance) with no degraded. Two options:

- Lighter: don't change the status model. Provider checks expose a configurable mapping for whatever states a backend reports, so you decide per-monitor whether a reported "degraded" counts as up or down (upgrade/downgrade as configured). Zero ripple, ships fast, but loses the nuance on the page.
- Bigger: add a real degraded state. Additive to the enum, but it ripples through the DB, status-page colours, uptime math, notification rules, the UI, and the metrics exporter. Some people will genuinely want this rather than a binary.

These aren't mutually exclusive: the configurable mapping is useful even if a degraded state lands later, and could be the v1 while gauging whether degraded is wanted. Flagging it because the status-model decision is really a maintainer call.

## Describe alternatives you've considered

- Embedding the Peekaping status page inside a larger external status page: works, but you lose visual coherence
and a single source of truth.
- A separate status-aggregator tool alongside Peekaping: another component to deploy and keep in sync, it
doesn't share Peekaping's notifications/history, and at that point it becomes simpler to just do the checks against our own app in the monitoring app we maintain.
- Worth noting that official status feeds are coarse and lag (a green vendor dashboard during an outage is a well-known failure mode), so a synthetic canary, which Peekaping can already do with an http monitor, is often a truer signal. Provider integrations should complement those, not replace them.

## Additional context

Worth noting this is a genuine gap in the FOSS space, not just a nice-to-have. The existing open-source status tools (Uptime Kuma, Cachet, Gatus, etc.) monitor your own endpoints well, but none of them ingest upstream vendors' official status feeds as first-class dependencies. The closest comparable is Atlassian Statuspage's "third-party components", which is paid and hosted. So this would put a recognisable Statuspage feature into a self-hosted tool.

Happy to contribute code if there's interest. Mainly wanted to check for interest, and in particular your preference on the degraded-state question, before anyone starts building, since that drives how invasive the change is and how much time we need to put in.

The executor.Executor interface is the plugin entry point; start by reading its Execute/Validate/Unmarshal methods. Examine how existing executors produce a Result. The work involves designing new executor types, integrating external APIs, and potentially modifying the status model and database schema. 'Done' means external status feeds appear as monitors with full history, notifications, and metrics export.

由索引模型根據 Issue 內容生成。