feat(notification): route to source app output

[Accel-White]

Summary

• Add a default-off notification.route_to_source_output setting and matching Notifications → Toasts toggle
• Route a toast to the single eligible output containing a matched source-application window
• Re-evaluate routing when toplevels, outputs, or notification configuration change
• Preserve the existing selected-monitor behavior when source output matching is disabled, unavailable, or ambiguous

Motivation

On multi-monitor desktops, the source application can be on one output while focus is on another. Mirroring the same notification on every selected output is distracting, while focus-based routing can send it away from the source application.

Type of Change

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

Related Issue

Closes #4043

Testing

• just format
• find src tests \( -name '*.cpp' -o -name '*.h' \) -print0 | xargs -0 clang-format --dry-run -Werror
• just build
• just test debug --print-errorlogs — 91/91 passed
• python3 tools/i18n-check.py
• git diff --check
• Manually verified the unique-output routing path on a two-monitor Niri session: a Chrome notification appeared only on Chrome's DP-1 output while Alacritty held focus on HDMI-A-2

Manual Coverage

• Tested on Niri
• Tested on Hyprland
• Tested on Sway
• Tested on another compositor:
• Tested with different bar positions and density settings
• Tested at different interface scaling values
• Tested with multiple monitors

The manual routing check used outputs at 1.0 and 1.25 scale. The PR branch was also built and exercised by the full automated test suite on current main.

Screenshots / Videos

Not attached because the full-desktop capture contained unrelated private content. The live check confirmed one toast on the matched output and no duplicate on the other output.

Checklist

• This PR is ready for review, or it is marked as Draft.
• I read and followed the relevant guidance in CONTRIBUTING.md.
• I ran just format with clang-format v22+ installed, or this PR has no code changes.
• I ran the relevant build or test commands, or explained why they were not run.
• I self-reviewed the changes.
• I checked for new warnings or errors.
• I will update end-user documentation after merge, or this PR does not change user-facing configuration or behavior.
• I added or updated assets/translations/en.json, or this PR adds no new user-facing strings.
• I did not edit non-English translation files unless this PR is explicitly for translation tooling, an import/export sync, or a maintainer-requested locale change.
• I used the existing canonical names for config keys, IPC names, paths, and identifiers.

Additional Notes

notification.monitors remains the allow-list. Routing only selects a target inside that list.

Desktop notifications do not carry a portable originating toplevel identifier. If the same application has windows on multiple eligible outputs, this intentionally falls back to the current selected-monitor behavior instead of choosing an arbitrary window.