Multi-bridge Phase 2.9: Polish — filter chips, color picker, iPad, perf

[tashda]

Why

Phase 2 polish — small features that make the multi-bridge UX feel finished.

What

• "All bridges" filter chips on Logs and Devices views (chip group: All, then one per bridge).
• Bridge color picker in Saved Bridges screen — drives the badge color used everywhere (Add CI, release workflow, and bump version to 1.1.0 #2.4 BridgeBadge).
• Performance audit: confirm two concurrent connections don't double main-thread work. Z2MWebSocketClient is an actor; routing happens off main; store mutations should batch via existing apply(_:) debouncing if any.
• iPad: Home merged view uses a wider/multi-column layout; per-bridge view uses side-by-side columns.

Files

• Shellbee/Features/Logs/LogsView.swift, Shellbee/Features/Devices/DeviceListView.swift — chip group.
• Shellbee/Features/Settings/SavedBridgesView.swift — color picker.
• Shellbee/Features/Home/HomeView.swift — iPad layout pass.

Verification

• Performance: two bridges connected, run Implement stateful Z2M engine and enhance UI test coverage #1.6's spam scenario on both simultaneously; CPU usage stays reasonable on the main thread.
• iPad: rotate device, both layouts adapt.

Phase

Phase 2 of multi-bridge support. Depends on #2.3, #2.4.

[tashda]

Phase 2.9 polish landed across 427ad44 (Multi-bridge correctness pass + UX revision) and f40a68a (typed bridge routes, attribution components, color tokens, Settings refactor). Color picker tracked via the deterministic DesignTokens.Bridge palette.