Plugin BLE binding and Sensor discovery checkpoint

[ODevStudio]

Summary

• Add host.devices.bindDriver() and host-owned BLE bindings with synchronous factories, session-scoped GATT/publication, and bounded teardown.
• Wire plugin-first ownership into the existing scanner, system results, watch, startup readiness, and native connection admission. Pending/conflict cannot select native; unconfirmed teardown retains physical exclusion.
• Prove a BLE Sensor through real JavaScript, existing DeviceController/SensorController selection, HTTP inventory/commands, and WebSocket snapshots with a fake BLE edge. Reuse the Scale adapter without claiming Bookoo or Scale timing acceptance.

This is the review-ready BLE binding and Sensor checkpoint after merged #813, not completion of #809. Its merge boundary is host-owned BLE arbitration/lifecycle and Sensor integration through existing controllers and APIs, verified with a fake BLE edge.

Linked Issue

Refs #809. Keep the issue open.

Verification

• Formatter: 818 files, zero changes using the CI-compatible dart_style 3.1.13 formatter.
• flutter analyze --no-pub: no issues.
• Full flutter test --no-pub --machine: 3,992 passing tests, one skip. The 20-second per-suite active-time gate passes.
• Regression coverage includes failed initial plugin loading, both evidence orders, conflict/pending deadline, native candidate fencing, failed handshake without native fallback, repeated permanently hung connects, throwing/hung cleanup, unconfirmed native teardown, capacity/isolation, stale/foreign authority, and terminal delivery on link loss/revocation.
• Real UniversalBleTransport bridge test verifies notification -> disabled -> notification, UUID aliases, old logical unsubscribe isolation, missing attributes, cancellation, and acknowledged-write errors without downgrade.
• Windows debug build (lib/main.dart, simulate=1) passed using CMake 3.28 and Visual Studio 2022 in a separate build directory. Flutter's default VS2019 toolchain failed on native dependencies; no global toolchain settings or dependency sources were changed.
• Desktop runtime smoke: an isolated Flutter entrypoint using the production manager, discovery, controllers, and Sensor routes with fake BLE/in-memory settings passed. HTTP inventory reported the connected Sensor; command returned {"status":"ok","result":{"humidity":52}}; a fresh WebSocket notification returned {"humidity":57}. Runtime exited after teardown. No real BLE/USB devices or saved user data were used. This is not full application UI/hardware acceptance.
• Deliberately rejected JavaScript promises produce QuickJS rejection diagnostics in failure-path tests; assertions observe the expected errors. No hardware test was performed.

Subsequent #809 checkpoints cover Bookoo protocol, Scale measurement timing, automatic optional Scale operations, and sleep policy. Exhaustive reload/discovery interleavings and physical hardware acceptance remain broader #809 acceptance work; they are not claimed by this checkpoint. #809 remains open.

Latest ownership-contract verification at 75e8ec6e: all 10 discovery-policy tests pass, including occupied native ownership through plugin load and loaded-but-unbound declaration fallback. Full suite: 3,992 passed, one skipped; analysis clean; formatter and 20-second suite timing gate pass. No production code changed in this follow-up. Native build/runtime smoke above are prior checkpoint evidence, not rerun for this test/doc-only change.

Impact

• BLE plugin Sensors use existing inventory, command, and snapshot routes; no REST/WebSocket route or payload schema change and no database migration.
• Plugin loading now gates initial BLE selection. A matching runtime-bound plugin takes precedence over unoccupied native candidates; unresolved evidence or conflicting matchers excludes native selection.
• Publication and GATT authority are connection-bound. Native and plugin candidates share physical exclusion until confirmed teardown. No new dependencies, scanner, retry scheduler, or BLE calls outside the transport abstraction.
• Update Plugins, DeviceManagement, and AI_BLE_NOTES; archive this checkpoint's design rationale while the broader Plugin drivers: host-owned BLE binding + plugin-backed Scale support #809 design remains active.

Contributor Responsibility

AI-assisted development is allowed. The submitter remains responsible for the submitted work.

• I have reviewed and understand all changes in this PR and take responsibility for their correctness, security, behavior, licensing, and provenance, including any AI-assisted or AI-generated work.

[tadelv]

The implementation direction looks consistent with #749/#809, and the existing coverage is strong, but I think two central ownership cases still need explicit contract tests before this checkpoint lands:

1. Do not hot-swap an already-connected native owner. #809 explicitly says an occupied device keeps its current owner and enabling a matching plugin must not replace an active native connection. The current plugin-first ownership fences old native candidate test covers a discovered/unconnected native candidate: it loads the plugin first, then verifies the stale native candidate cannot connect. Please add the complementary case where the native candidate connects and owns the physical ID first, then a matching plugin is loaded. Assert the native connection remains untouched/no plugin transport is created while it is occupied, and that plugin ownership can only be selected after normal native teardown plus subsequent discovery/reconciliation.

2. A loaded BLE declaration without a runtime bindDriver must remain native-eligible. This is another explicit fallback condition in #809 and is materially different from the plugin being absent or failing to load. Please cover a successfully loaded plugin whose manifest declares the matching BLE driver but whose runtime never binds it, and verify the existing native candidate is still selected.

These are both first-order ownership rules rather than timing/fuzz/edge cases, and they protect the main #749 boundary: Decaid owns arbitration/lifecycle and a plugin only participates once it has a valid runtime driver binding.

Non-blocking cleanup while touching this: the PR is currently marked ready for review, but its description/archive plan still say This PR remains draft / Status: draft checkpoint and describe later stack slices as remaining merge-readiness work. It would be clearer to update that wording so #820's actual merge boundary is explicit.