winrtble: also receive on the Coded PHY where supported

[userepo]

What

One line in BLEWatcher::start: enable UseCodedPhy(true) on the
BluetoothLEAdvertisementWatcher, next to the existing unconditional
SetAllowExtendedAdvertisements(true) and with the same error-ignored
pattern.

Why

Without it, the Windows backend never receives BLE 5 coded-primary
(long range) advertisements, even on adapters that support them.
Extended advertisements are announced on the primary channels using
either the 1M or the Coded PHY (2M is secondary-channel-only, and the
controller follows AUX pointers to any secondary PHY automatically);
AllowExtendedAdvertisements alone leaves the scanner listening on 1M
primaries only. UseCodedPhy is documented to take effect only
alongside AllowExtendedAdvertisements, which this watcher already
sets, so this completes the pair.

The call fails harmlessly on systems without Coded PHY support (older
Windows builds / non-coded adapters); the error is ignored exactly like
the extended flag above it, so behavior there is unchanged. On supported
systems, 1M reception is unaffected — coded scanning is additive.

[userepo]

Hi @qwandor, the Linux job on this PR is failing at the "Run clippy" step. Two things show up in the log:

Exiting due to clippy errors

Error: Unable to create clippy annotations! Reason: HttpError: Resource not accessible by integration
Warning: It seems that this Action is executed from the forked repository.
Warning: GitHub Actions are not allowed to create Check annotations, when executed for a forked repos.
See https://github.com/actions-rs/clippy-check/issues/2 for details.

The second part looks like the known actions-rs/clippy-check limitation on fork PRs (unmaintained action, no write access to post annotations from a fork). Is that expected/ignorable on this repo, or are there existing clippy findings on a target branch underneath causing the actual failure?

[qwandor]

It looks like there are a bunch of existing clippy warnings but they are unrelated to the change so you can ignore them for now. I think @qdot should review this though, I'm not very familiar with the Windows side.

[userepo]

I think @qdot should review this though, I'm not very familiar with the Windows side.
It seems that @qdot might be busy/unavailable right now; @qwandor, is there anyone else who could take a look at the outstanding clippy warnings in the meantime?

[qdot]

I'm actually around, I just gotta actually check my PR mail heh. Lemme see what we can do on this, since I also need to take a look at #465, see if I can bring tests for these into our embedded system, etc.