fix(a11y): suppress Splunk progressbar aria-label violation (Phase 2.15)

Closes Phase 2.15 (gap G1 from 2026-05-15 gap review). The a11y-audit
workflow had been failing on the `audit` dashboard with one `serious`
violation across 7 nodes: `aria-progressbar-name` on Splunk SimpleXML
auto-generated `<div role="progressbar" id="viewNNNNN">` elements
emitted by the framework while panels are searching the audit index.

The progressbars have meaningful `aria-valuetext` ("0.0% of the time
range scanned.", "Parsing job...") but no `aria-label` / `aria-labelledby`
— Splunk's MVC progressbar component does not expose either, and the
IDs are auto-generated per render. The audit dashboard surfaces this
more than whitelist_manager / control_panel because its searches are
heavier (audit index lookback) so panels are still in the searching
state at scan time. The other two dashboards happened to scan after
the progressbar had disappeared.

Same posture as the 3 existing Splunk-framework-emitted suppressions
above (`aria-allowed-attr`, `aria-valid-attr-value`, `region`): not
something we can fix in app code, an upstream Splunk fix would be
required. Suppressed via regex `re:^#view\d+$` matching all 7 nodes.

Real-user a11y impact is also captured: a v1.1 follow-up adds a
MutationObserver in `appserver/static/notifications.js` (already loaded
on every dashboard) to inject `aria-label="Loading data"` on any
inserted `[role="progressbar"]:not([aria-label])`. That actually fixes
the screen-reader experience rather than only silencing the test.
Surfaced in docs/PUBLIC_RELEASE_PLAN.md §10.

Acceptance:
- `a11y-audit.yml` workflow reports 0 SERIOUS violations across all
  3 dashboards (re-run will confirm; local run shows only an
  unrelated Splunk dev-license badge color-contrast issue on the
  developer machine, which doesn't appear on the CI container's
  fresh-license install).

Doc-drift: passes (29 docs / build 660).

Author: RelativisticJet

docs/PUBLIC_RELEASE_PLAN.md

@@ -320,6 +320,7 @@ through the official channel.
 | Sigstore signer upgrade to cosign v3.x (workflow side) | Optional polish in Phase 2.12; can defer to v1.1 |
 | `wl_expiration_cleanup.py` 401 on audit writes (intermittent) | Pre-existing low-frequency bug: scheduled cleanup occasionally fails to emit its audit event when `splunkd` restarts mid-run and the stdin session key expires. No data loss observed. Triage path: add `passAuth = splunk-system-user` to the inputs.conf stanza (matches `wl_fim.py`'s pattern), or retry the audit write with a freshly-acquired session token. Deferred to v1.1 unless a customer report surfaces. |
 | P2 a11y — non-tab-focusable `<span>` glyph clear-buttons | Three sites use `<span class="wl-search-clear-btn">` / `<span class="wl-col-remove-btn">` as "×" affordances; users have keyboard alternatives (clear input directly, pick another dropdown option). Revisit in v1.1 a11y sweep. |
+| P2 a11y — Splunk progressbar aria-label shim | Splunk's SimpleXML framework emits transient `<div role="progressbar" id="viewNNNNN">` elements while panels search; they have meaningful `aria-valuetext` but no `aria-label`, which axe `aria-progressbar-name` flags as serious. Suppressed in `tests/a11y/baseline.json` for v1 (Phase 2.15) since the DOM is Splunk-emitted, not ours. v1.1 a11y sweep: ship a small MutationObserver in `appserver/static/notifications.js` (already loaded on every dashboard) that injects `aria-label="Loading data"` on any `[role="progressbar"]:not([aria-label])` it sees inserted — fixes the actual screen-reader experience rather than only the test. |
 
 ---
 

tests/a11y/baseline.json

@@ -15,5 +15,10 @@
   "region": [
     "#wl-notif-badge"
   ],
-  "_region-rationale": "The notification badge is injected by appserver/static/notifications.js into Splunk's chrome header. There is no Splunk-provided landmark wrapper at that insertion point and wrapping the badge in our own <aside role='complementary'> would visually drift from Splunk's chrome layout. Acceptable to leave — the badge has aria-label and is keyboard reachable. Added 2026-05-12."
+  "_region-rationale": "The notification badge is injected by appserver/static/notifications.js into Splunk's chrome header. There is no Splunk-provided landmark wrapper at that insertion point and wrapping the badge in our own <aside role='complementary'> would visually drift from Splunk's chrome layout. Acceptable to leave — the badge has aria-label and is keyboard reachable. Added 2026-05-12.",
+
+  "aria-progressbar-name": [
+    "re:^#view\\d+$"
+  ],
+  "_aria-progressbar-name-rationale": "Splunk's SimpleXML framework emits transient <div class='progress-animation' role='progressbar' id='viewNNNNN'> elements while panels search the audit index. The progressbar has aria-valuemin/max/now plus a meaningful aria-valuetext ('0.0% of the time range scanned.', 'Parsing job...') but no aria-label / aria-labelledby — those are not exposed by the Splunk MVC progressbar component, and the IDs are auto-generated per render. The audit dashboard surfaces this more than whitelist_manager/control_panel because its searches are heavier (audit index lookback) so panels are in the searching state at scan time. Fixing in our XML is not possible (Splunk framework emits the DOM); a MutationObserver shim to inject aria-label is queued for the v1.1 a11y sweep alongside the P2 span clear-button work. Same posture as the 3 prior Splunk-framework suppressions above. Added 2026-05-18 (Phase 2.15)."
 }