Group ARC runners by mt-* label on runners HUD (#8097)

Runners with names like `mt-l-x86aavx2-189-704-a10g-8-c8z6d-runner-4q77c` were all collapsing into the `unknown` bucket on https://hud.pytorch.org/runners/pytorch.

OSDC runners for some reason are registered on GitHub with `labels: []` and `os: "unknown"` (checked by running `orgs/pytorch/actions/runners` API directly). The label-based grouping in `getRunnerGroupLabel` has nothing to match on, and the existing name-based fallback only recognizes dotted prefixes (ROCm-style), so every ARC pod fell through to `unknown`.

Fix: parse the runner name. ARC pod names always have the shape `<scaleset>-<replicaset-hash>-runner-<pod-hash>`, where `<scaleset>` is also what workflows put after `runs-on:` and what is stored in `torchci/lib/arcRunnerMapping.ts`. A new fallback regex `^(mt-.+)-[a-z0-9]+-runner-[a-z0-9]+$` strips the suffix and returns the scaleset, so all pods in the same scaleset now group together.

Today only the `mt-` (Meta) provider prefix is in active use. A `TODO` is left to expand to other providers (`lf/am/in/nv/ib`) and the `c-` canary prefix once those fleets come online. The scaleset format is documented in [pytorch/ci-infra:osdc/docs/runner_naming_convention.md](https://github.com/pytorch/ci-infra/blob/main/osdc/docs/runner_naming_convention.md):

```
[c-]{provider}-[rel-]{os}-[b]{arch}{vendor}{features}-{vcpu}-{memory}[-{gpu}[-{n}]]
```

Also drive-by: the search bar now trims leading/trailing whitespace before filtering, so a stray space no longer breaks results.

Author: malfet

torchci/lib/runnerUtils.ts

@@ -32,7 +32,8 @@ export interface RunnersApiResponse {
 export function getRunnerGroupLabel(runner: RunnerData): string {
   const labelNames = runner.labels.map((label) => label.name);
 
-  // Find labels with "." (excluding any that end with ".runners") or starting with "macos-"
+  // Find labels with "." (excluding any that end with ".runners") or
+  // starting with "macos-".
   // Why have such funky logic? We have many labels on our runners today, but this
   // is what's common in all the ones that jobs actually use.
   const validLabels = labelNames.filter(
@@ -55,6 +56,19 @@ export function getRunnerGroupLabel(runner: RunnerData): string {
   // but use naming conventions like: linux.rocm.gpu.gfx942.1-xxxx-runner-xxxxx
   const runnerName = runner.name;
 
+  // ARC/OSDC runners register with empty labels and pod names of the form
+  // <scaleset>-<replicaset-hash>-runner-<pod-hash>, e.g.
+  // mt-l-x86aavx2-189-704-a10g-8-c8z6d-runner-4q77c. We want to group by the
+  // scaleset prefix (mt-l-x86aavx2-189-704-a10g-8), which is also what
+  // workflows put after `runs-on:`. The scaleset name format is documented at
+  // pytorch/ci-infra:osdc/docs/runner_naming_convention.md
+  // TODO: today only "mt-" (Meta) is in active use; expand to other providers
+  // (lf/am/in/nv/ib) and the "c-" canary prefix when those fleets come online.
+  const arcMatch = runnerName.match(/^(mt-.+)-[a-z0-9]+-runner-[a-z0-9]+$/i);
+  if (arcMatch) {
+    return arcMatch[1];
+  }
+
   // Look for dotted prefixes before "-" followed by random suffix
   const namePatterns = [
     /^([a-z]+\.[a-z0-9.]+)-[a-z0-9]+/i, // linux.rocm.gpu.gfx942.1-xxxx

torchci/pages/runners/[org].tsx

@@ -161,9 +161,10 @@ export default function RunnersPage() {
   const filteredAndSortedGroups = useMemo(() => {
     let groups = runnersData?.groups || [];
 
-    // Filter based on search term
-    if (searchTerm) {
-      const term = searchTerm.toLowerCase();
+    // Filter based on search term (ignore leading/trailing whitespace)
+    const trimmedSearch = searchTerm.trim();
+    if (trimmedSearch) {
+      const term = trimmedSearch.toLowerCase();
       groups = groups.filter(
         (group) =>
           group.label.toLowerCase().includes(term) ||