Incorrect scroll wheel behavior in native Linux build under Wayland sessions

## Summary
In the native Linux build of Substance 3D Designer, the mouse scroll wheel does not behave as intended when the desktop session is running under **Wayland**. Under an **X11** session, behavior is correct. This affects both the 2D node graph view and the 3D viewport.

## Affected versions
- Substance 3D Designer 2025 — confirmed
- Substance 3D Designer 2026 — confirmed (identical behavior)
- Substance 3D Designer 2022 — **not affected** (correct behavior under Wayland)

This indicates a regression introduced sometime between the 2022 and 2025 releases, coinciding with viewport/rendering changes (2025/2026 logs show a Hydra-based viewport, `LayaHydraEngine` / `HdEclairRendererPlugin`).

## Environment
- OS: Arch Linux
- Desktop: KDE Plasma 6, Wayland session (native, not XWayland-forced)
- GPU: NVIDIA GeForce RTX 3090, proprietary driver 610.43.03 (Vulkan)
- Qt platform plugin loaded by Designer: `xcb` (confirmed via `QT_DEBUG_PLUGINS=1`; the Designer window itself renders through XWayland/GLX by default even in a Wayland session)

## Expected behavior
- Node graph view: scroll wheel zooms in/out (closer/farther), matching X11 session behavior.
- 3D viewport: scroll wheel zooms/dollies the camera, matching X11 session behavior.

## Actual behavior (Wayland session only)
- Node graph view: scroll wheel pans along the Y axis instead of zooming.
- 3D viewport: scroll wheel rotates/orbits the camera instead of zooming/dollying.
- Switching the desktop session to X11 (same machine, same hardware, same mouse) restores correct behavior immediately, with no other changes.

## Diagnostic steps already performed
We spent significant effort trying to isolate this before filing, ruling out several likely causes:

1. **Forced XWayland via `QT_QPA_PLATFORM=xcb`** — confirmed via `QT_DEBUG_PLUGINS=1` that the `xcb` platform plugin and `xcb_glx` integration are loaded and used. Bug persists identically.
2. **Hid Wayland session markers from the process** (`env -u WAYLAND_DISPLAY XDG_SESSION_TYPE=x11`) — no change in behavior.
3. **Verified raw input at the X11 level** using `xev`: scroll wheel produces standard, correctly-formed discrete `ButtonPress`/`ButtonRelease` events (button 4 / button 5), identical to what a normal X11 session would produce. No smooth-scroll, no gesture events, nothing unusual reaches the X11 client layer.
4. **Checked for a system-wide Wayland/libinput issue**: other Qt-based applications (Krita, Blender, Kdenlive) under the exact same Wayland session behave correctly — only Substance Designer is affected. This rules out a KWin/libinput/compositor-level problem.
5. **Traced with `strace`**: found that a separate thread/process within Designer opens `libwayland-client.so` and directly connects to the Wayland compositor socket (`/run/user/1000/wayland-0`), independent of the XCB/X11 window and input path used by the rest of the UI. This suggests the viewport/camera-navigation code has its own direct communication path with the Wayland compositor, separate from the input Qt receives through XCB.
6. **Blocked this direct Wayland socket connection** for the process via a mount namespace (bind-mounting an empty file over the socket) while preserving X11 authentication — behavior did not change, ruling out a simple "just refuses to connect, falls back incorrectly" explanation.

## Conclusion from our own testing
The bug does not originate from:
- the X11/XWayland input path (verified clean at the X11 protocol level),
- the desktop compositor or libinput (other Qt apps unaffected),
- a straightforward "detects Wayland via env var" or "detects Wayland via direct socket connection" check (both ruled out).

This points to session-type detection happening through some other mechanism entirely internal to the application (e.g. a D-Bus/systemd-logind session type query, or some other compositor capability check) that changes how the viewport/graph-view input handling code interprets scroll input — independent of which windowing backend is actually rendering the window.

## Additional notes
- This has been previously reported informally in the Steam Community discussions for Substance 3D Designer without any response from developers.