[Feature] Group monitored URLs using Grafana custom labels

[kilemensi]

Problem

ProbeView currently renders every discovered Grafana Synthetic Monitoring check in one flat list. This becomes difficult to scan when an installation monitors several URLs for the same product or service family, such as a public frontend, API, admin interface, and authentication endpoint.

The grouping source should remain in Grafana rather than introducing a second service inventory in ProbeView. Grafana Synthetic Monitoring supports custom labels on checks and exposes them on sm_check_info with a label_ prefix, which gives ProbeView suitable metadata for dynamic grouping.

There is also an adjacent routing issue to account for: checks are deduplicated by (job, instance), but the current route ID is derived only from job. Checks that share a job name can therefore collide.

Proposed solution

Add optional, environment-configured grouping based on a Grafana Synthetic Monitoring custom label.

Suggested configuration:

SM_GROUP_LABEL=product
SM_PURPOSE_LABEL=purpose

For a check configured in Grafana with:

product = PesaCheck
purpose = API

ProbeView would read label_product="PesaCheck" as the group display name and optionally render label_purpose="API" as compact secondary metadata on the check row.

Overview UI

• Render named groups as unframed sections in the existing overview rather than nested cards.
• Keep every monitored URL as an independent row linked to its existing detail history.
• Keep groups expanded by default so an affected check is never hidden.
• Show explicit impact summaries such as All 3 operational, 1 of 3 affected, or Status unavailable for 1 of 3.
• Use the worst child status for the group indicator, but do not label the entire group simply Down when only one child is affected.
• Preserve a stable group order and apply the selected sort within each group.
• Search across group name, check name, target URL, and optional purpose.
• When a group name matches the search query, show the whole group; otherwise show only matching child checks under their group heading.
• Preserve the current compact responsive layout. On narrow screens, prioritize name, purpose, status, and the selected metric.
• Checks without the configured group label remain usable and appear in a clearly named fallback section such as Other services. When no checks have grouping metadata, preserve the current flat presentation.

Data and configuration

• Extend the shared Check domain type with optional group and purpose metadata.
• Read the configured label_<name> values from sm_check_info during check discovery.
• Keep Grafana access server-only and keep the feature stateless.
• Do not hardcode groups or service membership in ProbeView.
• Ensure route IDs uniquely identify (job, instance) pairs while considering compatibility for existing detail URLs.
• Add representative grouped and ungrouped checks to mock data.
• Document the new environment variables and the required Grafana custom-label setup.

Acceptance criteria

• An installation can select the Grafana custom label used for group names through an environment variable.
• Checks with the same configured label value render in one named overview section.
• Checks remain independently clickable and retain individual uptime and latency histories.
• Group summaries accurately communicate the number of affected children.
• Search and sorting behave predictably across grouped results.
• Missing grouping labels degrade gracefully, including installations with no group labels at all.
• Duplicate job names with different target instances produce unique rows and detail routes.
• Mock, unit/component, and end-to-end coverage includes grouped, partially affected, ungrouped, and duplicate-name cases.
• .env.example, README.md, docs/configuration.md, and docs/architecture.md describe the behavior.

Alternatives considered

• Hardcoded groups in ProbeView configuration: rejected because it creates a second inventory that can drift from dynamically discovered Grafana checks.
• Infer groups from hostnames or check names: rejected because naming conventions are ambiguous and installation-specific.
• Treat a group as one aggregated service: deferred because aggregation requires policy decisions about critical versus ancillary endpoints and how group uptime should be calculated.
• Nested or collapsible group cards: avoided initially because they add visual weight and can hide active failures.
• Two-level nested grouping: deferred. A single product-family section with optional purpose metadata provides useful hierarchy without turning the public page into an operations dashboard.

Additional context

Grafana custom labels are documented at:
https://grafana.com/docs/grafana-cloud/testing/synthetic-monitoring/analyze-results/custom-labels/

This feature should retain ProbeView's read-only, database-free architecture and dynamic check discovery.

[kilemensi]

Identity handling has been extracted into #10 because it is an existing correctness bug independent of grouping. The grouping implementation should use or follow the unique route-ID design established there.