[Bug] 1.5.0-beta.14: TransportError "Failed to read feature report (-1)" on startup → crash → device locked #604

Description

Since updating to 1.5.0-beta.14, StreamController crashes on every startup when
a Stream Deck is connected. The app detects the USB device but fails immediately
when reading the serial number via HID feature report.

This creates a crash loop: the hard crash (SIGABRT) leaves the hidraw device handle
open, so every subsequent start fails with "already connected to another instance"
until the USB cable is replugged — which just triggers the crash again.

Downgrading to the parent Flatpak commit (b4e16bf4...) fully resolves the issue.

Steps to Reproduce

1. Update to 1.5.0-beta.14 via Flatpak
2. Start StreamController with a Stream Deck MK.2 connected
3. App starts, detects the deck via on_connect, then immediately crashes

Expected Behavior

App starts and deck is recognized normally (worked in all previous versions).

Actual Behavior

StreamDeck.Transport.Transport.TransportError: Failed to read feature report (-1)

File "DeckController.py", line 853, in get_deck_settings
  return gl.settings_manager.get_deck_settings(self.deck.get_serial_number())
File "StreamDeckOriginalV2.py", line 107, in get_serial_number
  serial = self.device.read_feature(0x06, 32)
  raise TransportError("Failed to read feature report (%d)" % result)

After crash, subsequent starts produce:
ERROR | DeckManager:load_hardware_decks:129 - Failed to open deck.
Maybe it's already connected to another instance?

Root Cause Hypothesis

The issue appears to be related to the new Remote Deck / beta_resume_mode
introduced in beta.14. In DeckController.__init__, the deck is opened with
self.deck.open(beta_resume_mode=True), followed immediately by get_deck_settings()
which calls get_serial_number() → read_feature(0x06, 32).

The feature report read (HID report ID 0x06, 32 bytes = serial number) returns -1,
suggesting the device is opened in a state that doesn't yet support feature reports —
likely a timing or initialization issue introduced by the beta_resume_mode path.

Notably, the logs show:
INFO | DeckManager:init:78 - Beta resume mode: True
This flag appears to be set unconditionally in beta.14 (even without a remote deck
being used), which may be the regression trigger.

Environment

• OS: CachyOS Linux (Kernel 7.0.10-1-cachyos)
• StreamController: 1.5.0-beta.14 (Flatpak, system install)
  Commit: cf05ced6b1902e1c98a6dd9087b17ad0484825f1
• Device: Elgato Stream Deck MK.2 (USB 0fd9:0080, hidraw)
• Last working version: Parent Flatpak commit b4e16bf436eeb84d...

Workaround

Downgrade to the parent Flatpak commit:

pkill -f StreamController
sudo flatpak update \
  --commit=b4e16bf436eeb84d387cf8a34b0e6e6cdc7db0596c55580b6e55a78d3d25a892 \
  com.core447.StreamController
flatpak mask com.core447.StreamController

Additional Notes

- Related open issue: #601 (settings don't persist, same version) — different symptom,
possibly same underlying instability in beta.14
- The Flatpak build subject references "Retrigger build (#36)" — unclear if this is
a build system issue or a code regression