[2.x] fix: name the pane pin button and expose whether it is pinned

[imorland]

The button that pins the discussion list is icon-only and has no accessible name, so a screen reader can announce it as nothing more than "button". The back and drawer buttons on either side of it in the same component both label themselves, so this is an omission rather than a house style.

Core already detects it. Button.oncreate fires a debug warning when it finds a button with no content and no accessible label, and this button has been tripping that warning:

[Flarum Accessibility Warning] Button has no content and no accessible label. This means that screen-readers will not be able to interpret its meaning and just read "Button".

It is also a toggle. Its state was carried entirely by CSS — the thumbtack rotates 45° when unpinned — so whether the list was pinned was never exposed to assistive technology.

Change

• aria-label from a new core.lib.nav.pin_pane_button key, sitting alongside the existing drawer_button.
• aria-pressed reflecting pane.pinned.

The label names the control ("Pin Discussion List") rather than the action, so it stays stable while the state changes beneath it. Labelling it for the action instead ("Pin" / "Unpin") would mean a screen reader reading a button whose name changes under the user, with the state only ever implied.

Why aria-pressed is a string

Passing the boolean straight through does not work, and it fails silently. Mithril treats a boolean as an HTML boolean attribute:

passed	rendered
true	aria-pressed=""
false	attribute absent
"true" / "false"	aria-pressed="true" / aria-pressed="false"

ARIA needs the words. An empty value is invalid, and an absent aria-pressed makes the control read as a plain button rather than a toggle that happens to be off — so the boolean form is broken in both states. The first revision of this used aria-pressed={pane.pinned} and rendered no attribute at all; it typechecked and built cleanly, and only showed up when the rendered DOM was inspected.

There is no other use of aria-pressed in core, so there was no existing precedent to match.

Verified

Driven in a browser at a viewport wide enough for the pane, on a discussion page so the button renders:

• accessible name Pin Discussion List, role button
• aria-pressed moves false → true → false across two toggles, in step with the active class
• 0 core accessibility debug warnings on the page, where this button previously produced one
• back and drawer button labels unchanged; 149 unit tests pass; typecheck clean

Not in scope

Only this button. Since core uses aria-pressed nowhere else, other icon-only toggles may have the same gap — worth a sweep as separate work rather than widening this.