[Feature] Hide selected checks from the public status page using a Grafana custom label

## Problem

ProbeView currently discovers and publishes all Grafana Synthetic Monitoring
checks from `sm_check_info`.

Some checks target private, internal, staging, admin, or otherwise sensitive
URLs. We still want to monitor and alert on them in Grafana, but they should not
appear on the public ProbeView status page, and their data should not be included
in public-facing status queries.

## Proposed solution

Add optional server-side configuration to hide checks using a strict Grafana
Synthetic Monitoring custom-label match.

Suggested variables:

```env
SM_HIDE_LABEL=visibility
SM_HIDE_VALUE=private
```

Behavior:

- By default, all checks remain visible.
- When both variables are configured, only checks whose `sm_check_info` custom
label exactly matches `label_=""` are hidden.
- Checks without the label remain visible.
- Checks with the label set to any other value remain visible.
- Hidden checks should never land in the UI payload.
- Hidden checks should also be filtered out of PromQL queries, not merely
removed after fetching results.

Example:

```text
visibility = private
```

A check with that custom label would continue to exist in Grafana Synthetic
Monitoring and continue to alert there, but ProbeView would exclude it from:

- overview discovery
- uptime and latency PromQL queries
- grouping, search, sort, and aggregate public status rendering
- per-check detail lookup and history pages

Because Grafana Synthetic Monitoring custom labels are exposed on
`sm_check_info` with a `label_` prefix, the discovery query can filter with a
negative matcher such as:

```promql
sm_check_info{label_visibility!="private"}
```

For uptime and latency metrics, custom labels are not present directly on the
probe metrics, so ProbeView should filter them through a PromQL join against the
visible `sm_check_info` series. This keeps hidden checks out of public query
results rather than only dropping them in application code.

The feature should remain server-only: no `NEXT_PUBLIC_` variables, no hidden
label names or values sent to the browser, and no persistence.

## Alternatives considered

Use an allow-list label such as `visibility=public`.

That is safer for strict opt-in publishing, but it would be more disruptive for
existing installations. The desired behavior here is default-public with
explicit strict opt-out.

Filter hidden checks only after querying all metrics.

This is simpler, but it does not meet the privacy expectation. Hidden checks
should not be included in public-facing query results at all.

Maintain a static list of hidden URLs or check IDs.

This conflicts with ProbeView's dynamic discovery model and would be brittle
when checks are renamed or targets change.

## Additional context

ProbeView already reads custom labels from `sm_check_info` for grouping and
purpose labels, so this feature can reuse the same label plumbing. Grafana
documents that Synthetic Monitoring custom labels are exposed on `sm_check_info`
using the `label_` prefix and that probe metrics need a PromQL join when
filtering or propagating custom labels.

Reference:
https://grafana.com/docs/grafana-cloud/testing/synthetic-monitoring/analyze-results/custom-labels/

Implementation note: because `SM_HIDE_LABEL` is interpolated into PromQL label
syntax, ProbeView should validate it as a Prometheus label name before building
queries.

Trace the existing sm_check_info custom-label plumbing and the server-side PromQL query builders. Check how configuration is read and how discovery, uptime, latency, and detail queries are assembled. Validate the hide-label name before interpolation and verify that generated queries exclude matching checks while leaving unlabeled and differently labeled checks visible without exposing configuration to the browser.

Written by the indexing model from the issue text.