[Feature]: Add OTA actions to device long-press menu in device list

[tashda]

What problem does this solve?

To check or apply an OTA update today, the user has to drill into a device's detail screen and find the OTA section. For batch maintenance — sweeping through the device list to nudge each one — that's a lot of taps. The long-press menu on a device row is the natural place for quick maintenance actions, but OTA isn't there yet.

What would you like Shellbee to do?

Add OTA actions to the long-press / context menu on each row of the device list.

Items to add:

1. Check for Update — always visible. Sends bridge/request/device/ota_update/check with {"id": <friendlyName>}. Optimistically shows a checking spinner / state on the row.
2. Update now or Schedule update — only visible when the device's update.state is available. The label depends on power source, mirroring the logic in [Feature]: Schedule OTA update for sleepy/battery devices #12:
   • Mains-powered (power_source is mains/dc/etc.): label is Update now, sends bridge/request/device/ota_update/update.
   • Battery-powered (power_source: "Battery"): label is Schedule update, sends bridge/request/device/ota_update/schedule. Show the same hint as in [Feature]: Schedule OTA update for sleepy/battery devices #12: "Press a button on the device to trigger the update."
3. Cancel scheduled update — only visible when update.state is scheduled. Sends bridge/request/device/ota_update/unschedule.

Items appear at the bottom of the long-press menu, grouped under a divider so they don't compete with the existing actions (rename, remove, etc.).

State feedback:

• After tapping any OTA action, update the device row's status badge optimistically (Checking…, Update available, Scheduled, Updating…) to confirm the action took effect, consistent with the optimistic-UI pattern used elsewhere in Shellbee.

Does the Z2M web frontend already do this?

Partially — the web frontend exposes OTA controls per device but they live on the OTA page, not in a context menu. This is a Shellbee-specific affordance for mobile.

Alternatives you've considered

• Add OTA actions to the swipe action on each row — works but Shellbee already uses swipe for other actions and adding more crowds the gesture. Long-press menu is roomier and is the right place for "infrequent, per-device" actions.
• Bulk-only via "Check all devices for updates" ([Feature]: Schedule OTA update for sleepy/battery devices #12) — useful but doesn't replace per-device control. Some users want to nudge one specific device after a manual reboot or wake-up.

Related

• [Feature]: Schedule OTA update for sleepy/battery devices #12 (Schedule OTA update for sleepy/battery devices) — defines the battery-aware label logic this issue depends on.
• [Feature]: Live Activity for OTA updates in progress #11 (Live Activity for OTA updates in progress) — Live Activity should start regardless of where the OTA was kicked off, so triggering an update from the long-press menu surfaces in the Live Activity automatically.

[tashda]

Follow-up beyond the original scope (long-press menu only): the leading swipe action on the device list row now also exposes OTA controls, mirroring the long-press menu's logic — Check, then Schedule + Update Now (battery devices) or Update Now + Schedule (mains devices), and Cancel when the device is already in the scheduled phase. Same gating as the long-press menu (only when an update is available / device supports OTA). (Shellbee/Features/Devices/DeviceListRow.swift)

[tashda]

Polish on the firmware overflow menu: when no devices have an update available, the disabled "Update All Available" row now reads "No Updates" with a checkmark.circle icon, instead of "Update All Available" with no count. (Shellbee/Features/Devices/DeviceFirmwareMenu.swift)