fix(input): match thumb-button binds on BTN_BACK/BTN_FORWARD mice

[Saeverix]

Mice report their thumb buttons as either BTN_SIDE/BTN_EXTRA or BTN_BACK/BTN_FORWARD. MouseBack and MouseForward only matched the first pair, so binds on them never fired for mice using the second. A mouse bind now holds every code its name covers.

Fixes #445

Summary

MouseBack and MouseForward now match both evdev codes mice use for their thumb buttons:
BTN_SIDE/BTN_BACK and BTN_EXTRA/BTN_FORWARD. Keybind::mouseButton (one code) became
mouseButtons (every code the name covers), and handleMouseBind checks whether the pressed code
is in that list. The other uses of the field only changed their types. Presses that no bind consumes
still reach clients with their original code.

Motivation

Mice report their thumb buttons under one of two evdev pairs. Most use BTN_SIDE/BTN_EXTRA, but
some (the reporter's Logitech, for example) send BTN_FORWARD, so Mod+MouseForward never fired for
them.

Type of Change

• Bug fix
• New feature
• Breaking change
• Refactoring
• Build / packaging
• Documentation only

Related Issue

Fixes #445

Testing

Run in containers that mirror the CI "Build and test" and "Lint" jobs (archlinux:latest, same packages,
unprivileged user):

• just build: builds with -Werror
• just test: 65 passed, 0 failed. 49 skipped are umbrielfx renderer tests that need a GPU (exit 77).
• just lint: clang-tidy clean across all 203 files

Also built natively for Fedora 44 and run as a nested session (see Manual Coverage).

Manual Coverage

• Tested in a nested Umbriel session
• Tested in a native Umbriel session
• Tested with multiple monitors
• Tested with a scaled output
• Tested with native Wayland applications
• Tested with X11 applications through Xwayland
• Tested with the scrolling layout
• Tested with the dwindle layout

Mod+MouseBack / Mod+MouseForward work in a nested session with my mouse, which sends
BTN_SIDE/BTN_EXTRA. I don't have a mouse that sends BTN_BACK/BTN_FORWARD, so that path is
covered by the unit test only. It would be great if the reporter could confirm it.

Screenshots / Videos

Checklist

• This PR is ready for review, or it is marked as Draft.
• This change fits SCOPE.md, or its scope was agreed in an issue or on Discord first.
• I read and followed the relevant guidance in CONTRIBUTING.md.
• I ran just format, or this PR has no C++ changes.
• I ran the relevant build, test, lint, or verification commands, or explained why they were not run.
• I functionally verified compositor behavior where automated checks are insufficient.
• I self-reviewed the changes.
• I checked for new warnings or errors.
• I updated docs/ and examples/config.toml, or this PR does not change user-facing configuration or behavior.
• I used canonical names for config keys, IPC actions, paths, and identifiers.

Additional Notes

This is my first contribution to Umbriel, because I love Noctalia and Umbriel. It's also my first
change in a C++ project, so please be kind with the feedback. I'm an experienced C# developer, but
C++ needs a different mindset for many things.

AI disclosure: I wrote this change with Claude Code (an AI coding assistant). The AI wrote most
of the C++, while I directed and reviewed it. In review I pushed back on its first version, which
converted the pressed code with two new helper functions and also changed scroll_button. I asked
for the current approach instead: store every code in the bind and match against the list, with no
new helpers, and keep the change limited to keybinds. I also had it extend the existing
parsesMouseButtons test rather than add a separate one. I've gone through the final diff and
understand what it does, but I'd welcome extra scrutiny of the C++ itself.

Known trade-offs:

• A mouse that reports all four codes as separate buttons can no longer bind BTN_SIDE and
  BTN_BACK separately; both trigger MouseBack.
• scroll_button still uses a single code (its own list in fields_input.cpp), so
  scroll_button = "MouseForward" is still rejected on a BTN_FORWARD mouse. Left out to keep this
  PR to the ticket; happy to follow up if wanted.

[github-actions]

This pull request was converted to a draft because its description is missing required
parts of the pull request template.

Missing:

• the checked checklist entry: I functionally verified compositor behavior where automated checks are insufficient.

Add the items above to the description, keeping their exact wording, then mark the pull
request ready for review. That re-runs this check. Draft pull requests may leave boxes
unchecked. Before a pull request is ready for review, check exactly one change type (add
Breaking change alongside it when it applies) and check every item under Checklist. A pull
request should contain one feature, fix, or refactor; split unrelated changes.

Sections that only offer context may be deleted; nothing else about this pull request was
changed.