Multi-bridge Phase 2.6: Per-bridge OTABulkOperationQueue

[tashda]

Why

Today one OTABulkOperationQueue is wired into AppEnvironment. With two bridges running concurrent OTAs, they'd serialize through the same queue — a bridge A bulk check would block bridge B's update.

What

• AppEnvironment owns [BridgeID: OTABulkOperationQueue]. Lazily create on first connect to a bridge.
• Each queue's sender closure captures registry.send(bridge: id, ...) so it sends to the right WebSocket.
• AppStore.otaResponseForwarding becomes per-bridge — when a bridge/response/device/ota_* arrives tagged with bridgeID, it's routed to that bridge's queue.

Files

• Shellbee/App/AppEnvironment.swift — replace single queue with map.
• Shellbee/Core/Networking/OTABulkOperationQueue.swift — no internal change required, but verify nothing assumes singleton semantics.
• Shellbee/Core/Store/AppStore+OTA.swift — per-bridge response routing.

Verification

• Run OTA on two bridges in parallel via test center (POST /api/scenarios/ota/run); confirm each queue's progress and timeout settings are independent.
• UserDefaults concurrency/timeout settings (appOTABulkConcurrency, appOTABulkCheckTimeoutSeconds) remain global — applied to both queues equally. Document this.

Phase

Phase 2 of multi-bridge support. Depends on #2.1, #2.2.

[tashda]

Not addressed in the current multi-bridge batch (Phase 1 + Phases 2.1–2.5, 2.8, 2.9 shipped on dev). Bulk OTA queue remains single-instance for now; revisit if multi-bridge bulk OTA usage warrants per-bridge queueing.

[tashda]

Implemented as part of #82 (v1.6.0 multi-bridge support) — AppEnvironment now holds [UUID: OTABulkOperationQueue] with otaBulkQueue(for:) and lazy per-bridge creation in makeOrFetchQueue(for:bridgeID:). Despite being listed as deferred in the PR body, the implementation landed. Closing.