fix(hci): prevent duplicate raw connection fallback

[stoprocent]

What

• return separate L2CAP results for setup failure, connection success, and controller failure
• make the initial L2CAP connect() nonblocking so EINPROGRESS proves the kernel accepted the controller request
• wait for that accepted request synchronously to preserve the existing API behavior
• suppress the raw LE Create Connection fallback when the accepted kernel attempt later fails
• retain raw fallback when socket, bind, or initial kernel setup fails before an attempt starts

Why

The previous boolean path treated every failed blocking L2CAP connect() as “not handled.” When the controller had already completed an attempt with an error such as 0x3e, Write() then sent the original raw HCI command and launched a second controller attempt for one logical connection.

This matches the duplicate kernel/process command sequence being tracked in stoprocent/noble#97, noble#98, and noble#102.

Validation

Controlled Linux/arm64 kernel regression test using two BlueZ btvirt LE controllers and btmon:

1. hci1 advertised as a connectable peripheral.
2. hci0 received one JavaScript write() containing LE Create Connection.
3. A raw-HCI watcher on hci1 disconnected immediately after each successful controller connection, forcing the hci0 kernel L2CAP connect() to fail after the controller attempt had started.
4. The same test and command bytes were run against the merged baseline and this PR.

Revision	Controller-level LE Create Connection commands for one write()
e33de06 (merged baseline)	2
c38b39a (this PR)	1

Additional checks:

• reachable-peripheral path: this PR emitted one kernel connection command and completed the L2CAP connection
• immediate L2CAP setup-failure path: this PR still forwarded the raw HCI command
• Linux/arm64 native addon rebuilt successfully with node-gyp
• JavaScript lint completed
• all GitHub Actions checks are green across Linux, macOS, Windows, and Android builds

The repository's current test.js logs TypeError: BluetoothHCISocket is not a constructor on both the merged baseline and this PR, but exits successfully because it catches every construction error. It is therefore not meaningful runtime coverage for this patch; the direct native-addon/VHCI test above exercised the affected code path.

Fixes #21

[stoprocent]

CI note: the failing Windows jobs are a baseline runner/toolchain issue, not caused by this patch. They fail during npm ci because windows-latest now exposes Visual Studio 18 to node-gyp 10. The isolated workflow fix is #24; Linux/arm64, Linux/x64, Android, macOS, lint, and commit validation for this PR pass.

[stoprocent]

Temporarily stacked on #24 so CI uses the validated windows-2022 workflow without adding workflow commits to this Bluetooth patch. Merge order: #24 first; then retarget this PR to main. #24 is fully green, including win32 x86/x64 builds and Node 18/20 Windows tests.

[stoprocent]

CI is green after rebasing this branch onto #24: 27 build/test checks passed, including Node 18/20 on Windows and win32 x86/x64 prebuilds; only the expected release jobs were skipped.

The PR comparison remains limited to the three native socket files. Merge order: #24 first, then retarget #22 to main.

[stoprocent]

PR #24 is merged. This branch has now been rebased onto the resulting main commit and the PR base has been retargeted to main.

The comparison remains limited to the three native socket files. All current check runs are green, with no failures or pending jobs; release jobs were skipped as expected. The PR remains draft pending the documented Linux/BLE hardware validation.