fix(a11y): name the sliders and the progress bar where the role is

`a11y.md` lists `seek-bar` and `volume-control` under "what is already
correct" because both pass `aria-label`. Measured with
Accessibility.getFullAXTree against the running app on all eleven
views, both sliders compute a name of "": `wa-slider` puts
role="slider" on a div inside its own shadow root, pointing
aria-labelledby at an empty internal <label>, and that IDREF outranks
the host's aria-label. `volume-control` did not have the aria-label the
audit credits it with at all.

The name comes from `label` now, which is the library's own API — and
for a slider that is visible, so `styles/wa-slider-label.css.ts` hides
it by part. Preferred over reaching into the shadow root the way
name-dialog.ts must: if Web Awesome renames the part the label becomes
visible rather than silently nameless. The second rule in that file is
load-bearing — `#slider` takes an 8px margin the moment a label exists,
which grows the bar from 6px to 14px and moves the transport with it.

a11y.25 is the same family: wa-progress-bar maps `label` onto its inner
aria-label, falling back to the localised word "progress" — so it was
named after the widget rather than after the work, not unnamed.

The existing transport test asserted the host's aria-label and called
it an accessible name, so it was pinning the bug.

frontend/test/components/transport.test.ts

@@ -375,7 +375,11 @@ describe('<seek-bar>', () => {
   it('carries an accessible name, since it is otherwise an unlabelled slider', async () => {
     const el = await fixture('seek-bar');
 
-    expect(shadow(el, 'wa-slider')?.getAttribute('aria-label')).toBe('Seek');
+    // This asserted `aria-label` on the host for six phases, and the
+    // host is not what carries `role="slider"` — the name never
+    // reached the accessibility tree. `wa-control-names.test.ts` is
+    // the whole story; the name now comes from `label`.
+    expect(shadow(el, 'wa-slider')?.getAttribute('label')).toBe('Seek');
   });
 
   it('looks the way it did last time', async () => {