#### Brief overview of PR changes/additions
- `add-milestone` resolves the milestone by exact title first and then
by version prefix, so `5.0.0` finds `5.0.0 next release` again, and
fails loudly instead of assigning nothing. 191 PRs merged since 4.22.0
have no milestone.
- `TKeySequenceEditTest`'s two focus traversal cases no longer fail
under a bare Xvfb: ctest pins the offscreen platform on X11, and a
direct run without a window manager skips with a message instead of
burning the activation timeout twice.
#### Motivation for adding to Mudlet
Both were failing silently. The milestone step matched a title that no
longer exists and exited 0; and the traversal tests were the one red
mark in an otherwise green local suite, which everybody had to re-derive
as environmental.
The milestone lookup is now a script under `.github/scripts/`, covered
by a new `MilestoneResolutionTest` that runs it against a stubbed `gh`.
Re-introducing the original bug makes that test fail.
Worth knowing: `add-milestone` on this PR still assigned nothing,
because `pull_request_target` runs the copy of the workflow that is on
the base branch. It takes effect for pull requests opened after this
merges.
#### Other info (issues closed, discussion etc)
- Closes#9671 - CI: add-milestone silently assigns nothing - metadata
says "4.23.0" but the milestone is titled "4.23.0 next release"
- Closes#9575 - TKeySequenceEditTest: two traversal tests fail under
bare Xvfb (no window manager)
Test case: `ctest -R 'MilestoneResolutionTest|TKeySequenceEditTest'`,
plus `xvfb-run --auto-servernum ctest -R TKeySequenceEditTest` for the
case #9575 is about.
Assisted-by: Claude:claude-opus-5
#### Brief overview of PR changes/additions
- New `TKeySequenceEdit` widget replaces the stock `QKeySequenceEdit` in
the preferences Shortcuts tab: screen readers now announce each shortcut
editor with its label and current binding
- Tabbing through the shortcuts no longer erases stored bindings (bare
modifier presses and Shift+Tab were being captured as input)
- Adds a 13-test `TKeySequenceEditTest` unit test suite covering the new
behaviour
#### Motivation for adding to Mudlet
Screen reader users could not tell which shortcut they were editing or
what it was set to, and merely tabbing through the page silently wiped
their bindings.
#### Other info (issues closed, discussion etc)
Closes#8873
Verified with NVDA and an Axe.Windows UIA scan (editors now expose
accessible names/descriptions, no new violations).
**Test case:** Open Settings → Shortcuts with a profile loaded. With a
screen reader running, Tab through the shortcut editors: each announces
its label and current binding. Tab/Shift+Tab through all editors and
confirm no binding changes; click an editor, press a combination (e.g.
Ctrl+J), and confirm it is recorded.
---------
Signed-off-by: Andrew Johnson <andrew@johnson5.net>
