Problem
Just like #409 for characteristics.
On Windows, DeviceService.DiscoverServices returns services in the native enumeration order, not the order of the requested UUID list.
The public contract says: when a UUID filter is provided, the returned slice must have the same length and order as the requested UUID list. This is honored on darwin (see #416) / linux but not on windows.
Impact
Callers relying on index order receive swapped results.
Expected behavior
If filter UUIDs are provided:
- result slice length == len(filterUUIDs)
- order matches filterUUIDs
- error if any requested characteristic is missing
Actual behavior
Order matches enumeration order from WinRT.
Proposed fix
Build an ordered slice matching filter UUIDs (same logic as darwin/linux), including handling duplicate UUIDs.