feat: add asteroidz as a supported compositor

[asteroidzman]

Adds first-class support for asteroidz — a wlroots compositor of the dwl/mango lineage (dwm-style tags, nested-KDL config) — alongside the existing mango backend. The whole change is additive: no mango/niri/hyprland/sway path is removed or repointed.

Design

• Detection: CompositorService recognizes asteroidz via ASTEROIDZ_INSTANCE_SIGNATURE as its own compositor (isAsteroidz), independent of isMango.
• Shared dwl-tag path: mango and asteroidz share the same tag model, so shared gates use isDwlTagCompositor = isMango || isAsteroidz, and shared service calls (bar, dock, workspace switcher, keybinds, session, config) route through a single accessor:

  readonly property var dwlService: isAsteroidz ? AsteroidzService : (isMango ? MangoService : null)

  → mango keeps using MangoService, asteroidz uses AsteroidzService, one code path.
• asteroidz-only features (per-output HDR/VRR, named special workspaces) stay gated on isAsteroidz, so mango never enters those branches.

Contents

• AsteroidzService.qml — IPC/state service (parallels MangoService).
• core/internal/config/conf2kdl.go — DMS .conf → asteroidz nested-KDL (+ tests).
• core/internal/windowrules/providers/asteroidz_parser.go — window-rule parser (+ tests); additive windowrules.Actions fields.
• asteroidz cases in the config/windowrules/keybinds commands.
• Bar/dock/settings wiring, asteroidz icon + matugen templates, regenerated translations.

Testing status — please read

• ✅ go build ./... and the full Go test suite pass (incl. new conf2kdl / asteroidz_parser tests).
• ✅ qmllint reports no syntax errors across all changed QML.
• ⚠️ Not yet runtime-tested by me: I don't have both a mango and an asteroidz session to verify at runtime. The QML wiring is verified structurally (build + lint) but the dwlService routing and isMango || isAsteroidz gates should be exercised on a real mango session (to confirm no regression) and a real asteroidz session. Happy to adjust based on your testing / CI.

Notes

• Security/concurrency fixes from the same downstream audit are in a separate PR (core: fix security and concurrency issues found in a backend audit #2805); none of them are included here.
• Origin: the downstream fork github.com/asteroidzman/asteroidz-dms, being contributed back cleanly and additively.

[Purian23]

Hi there, thank you for inquiring about integrated support into DMS. At this time, the Team believes as your project is quite new, that it will be best to give it time to mature and gain a user base before implementation it into our project.

It's best to open a draft or discussion for matters like these going forward before you spend the time on PR integrations. Good luck and feel free to reopen a discussion in the future.

[bbedward]

New projects with this much code dependencies just add a lot of maintenance burden and they tend to iterate a lot and break a lot (like MangoWM itself has, between 1.4 and 1.5).

Personally I'd recommend keeping things tighter with MangoWM so its easier to just flip a flag (like Sway/Scroll) - once userbase and stability and adoption grows then do things like migrate to KDL configuration format and what not. But since this is so much new code to maintain, its a bit tough to want it in mainstream DMS.

Maybe if we had a mechanism to make compositor support more pluggable, that would be good for stuff like this.

[asteroidzman]

Sounds good, thanks, I realize it is a very big PR. Let's give it some time, thank you for your work!