Only restore braille on secure desktop exit, not on ordinary desktop switches (#20550)
Fixup for #18810
Summary of the issue:
Since #18810, NVDA frees the braille display when switching to the secure desktop and restores it
when returning to a user desktop. However, the restore branch also runs on desktop switches that
never entered the secure desktop. Moving input focus between a Remote Desktop session and the local
machine generates EVENT_SYSTEM_DESKTOPSWITCH in the remote session, so
braille.handler._onSecureDesktopStateChanged is invoked with isSecureDesktop=False even though
the secure desktop was never active. This re-runs braille display detection (or re-sets the
configured display), repeatedly disconnecting and re-detecting a working display. For remote braille
(e.g. RDAccess) each such switch causes a full channel teardown and re-handshake, so braille churns
on every alt+tab / focus change.
Description of user facing changes:
The braille display is no longer briefly disconnected and re-detected on desktop switches that do not
enter the secure desktop, such as switching between a Remote Desktop session and the local machine.
Description of developer facing changes:
None.
Description of development approach:
In BrailleHandler._onSecureDesktopStateChanged, when returning to a user desktop
(isSecureDesktop=False), only restore the display when the current display differs from
_lastRequestedDisplayName. Switching to the secure desktop replaces the display with the
noBraille fallback via setDisplayByName(..., isFallback=True), which deliberately does not update
_lastRequestedDisplayName. So a current display equal to _lastRequestedDisplayName means the
display was never freed (an ordinary desktop switch) and there is nothing to restore. This covers
both automatic detection (where _lastRequestedDisplayName holds the detected driver name) and a
manually configured display (where it equals the configured display). Entering the secure desktop is
unchanged, so the display is still freed there.