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

[maquchizi]

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:

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_<SM_HIDE_LABEL>="<SM_HIDE_VALUE>" 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:

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:

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.