[Tingsters]

On Windows, a VEX AIM (REV1, BLE firmware 1.0.0.b0) advertises both Notify and Indicate on its user/system output characteristics. The current preference selects Indicate: authentication succeeds, but the Python console receives zero bytes. A controlled Bleak run forced to indications reproduced the silence; notifications delivered the raw REPL and subsequent commands.

This change prefers Notify when both modes are advertised, while preserving indicate-only support. A regression test covers both modes, each individual mode and neither mode.

It also fixes two Windows connection-lifetime/error paths encountered during the same investigation:

• Retain an accepted preferred-connection-parameters request until replacement or device teardown, closing the previous request explicitly. Previously the request object was dropped immediately after checking its status.
• Propagate a failed GATT services status instead of returning an empty/stale service list that downstream code reports as missing characteristics.

Validation: cargo test --locked passes on Windows (47 active unit tests and five doctests; hardware-dependent radio/test-peripheral tests remain ignored). cargo fmt --all -- --check passes. Physical downstream checks with USB disconnected authenticated, ran Python, retrieved a native 640x480 camera JPEG and reconnected for another state read. The latest JPEG capture/download took 7.908 s with a measured 15 ms connection interval; request acceptance and actual negotiated interval were recorded separately. Camera images and credentials remain local.

cargo clippy --locked --all-features -- -D warnings also passes on Windows.

Hardware evidence is limited to that Windows/AIM firmware combination. Other peripherals and platforms have not had hardware acceptance for this change.

Downstream CI now passes on Linux x86_64, Windows x86_64, macOS arm64 and macOS x86_64: https://github.com/Tingsters/vex-aim-agent-workshop/actions/runs/39374119191. This covers the combined workshop build, isolated USB/Bluetooth transport tests, protocol validation, the vendored btleplug unit tests and installer checks. This is downstream software/build validation; it does not establish robot hardware acceptance on the other operating systems or replace this upstream repository's own CI/review.