Arrow keys don’t move the selection on Linux when desktop accessibility (AT-SPI) is enabled

Affects: QCAD with Qt 6 on Linux, since commit 921dd88adf (“update accessibility”, 2026-09-18).
Some Windows configurations might also be affected

Symptom: Pressing the arrow keys with entities selected does nothing: the selection doesn’t move and the view doesn’t pan. No screen reader needs to be running.

Steps to reproduce:

Turn on the desktop’s accessibility flag, without starting a screen reader:
gdbus call --session --dest org.a11y.Bus --object-path /org/a11y/bus --method org.freedesktop.DBus.Properties.Set org.a11y.Status IsEnabled ""
On-screen keyboards, automation tools and some apps set this flag on their own.
Start QCAD, select some entities and press an arrow key.
Alternatively, start QCAD with QT_LINUX_ACCESSIBILITY_ALWAYS_ON=1.

Expected: The selection moves by the configured step.
Actual: Nothing happens.

Cause: The key events do arrive at RMainWindowQt::event(). There, isCursorKeyReservedForScreenReader() decides the arrow keys belong to a screen reader and skips notifyKeyListeners(), so the QuickModify move listener is never called. It decides this with RSettings::isScreenReaderActive(), which is just QAccessible::isActive(). On Linux that turns true whenever org.a11y.Status IsEnabled is true, not only when a screen reader is running. The same false positive makes isKeyboardNavigationInListsEnabled() let the layer and block lists keep the arrow keys.

Workaround for existing builds: Start QCAD with AT_SPI_BUS_ADDRESS=unix:path=/nonexistent. This stops Qt’s accessibility bridge from connecting, so arrow keys work again; it’s verified with accessibility switched on. The catch is that screen readers can’t read QCAD’s interface in that process.