Pick the connected network adapter instead of the first counter instance - #3273

Fixes the network readings of the --system-information API landing on an
adapter that carries no traffic, so CurrentNetDown / CurrentNetUp stay at 0.

Related: #2377, #2915

Problem

HardwareUsageService.InitializePerfCounters() takes the first instance of the
Network Interface performance counter category and never looks at any other:

perfData.NameNetCard = GetNetworkCards().Count != 0 ? GetNetworkCards()[0] : null;

That instance is not necessarily a usable adapter, for two reasons.

Disconnected adapters are listed too. VPN, TAP and secondary NICs show up in
the same category and report 0 forever.

Adapter descriptions containing # produce a phantom instance. Windows
appends #2, #3 . to disambiguate adapters whose description is already
taken - routine after a mainboard swap or a driver reinstall. But # is also the
separator PDH uses for duplicate instance names, so a single adapter called
Realtek PCIe GbE Family Controller #2 surfaces as two instances: a phantom
base instance that always reads 0, plus the real one rendered as
Realtek PCIe GbE Family Controller _2.

And the order between them is not stable. On the reporting machine - one
physical NIC, exactly one PnP device, one class instance, no leftover registry
entry - GetNetworkCards()[0] returned the adapter that actually has a link in:

0 of 15 fresh processes under .NET Framework 4.7.2   (what the player runs)
13 of 25 fresh processes under .NET 9

So the phantom wins consistently in the player and it is a coin flip elsewhere.
Because the duplicate exists only in the counter namespace and not as a device,
users cannot fix it on their side.

Instance listing on that machine:

Realtek PCIe GbE Family Controller      Current Bandwidth =             0   (phantom)
Realtek PCIe GbE Family Controller _2   Current Bandwidth = 1_000_000_000   (actual NIC)

Fix

Choose the instance that reports a non-zero Current Bandwidth - i.e. the
adapter that actually has a link - and fall back to the previous behaviour when
no counter responds, so nothing regresses where this already worked.

Testing

Built from v2.2.1.0 with the patch applied, loaded against the dependency set
Lively ships in plugins\webview2, and exercised on the affected machine:

Measured throughput on that machine: phantom instance 0 B/s, real adapter
27_145 B/s down and 7_682 B/s up at the same moment.

• Single, normally named adapter: unchanged, same instance picked as before.
• All instances reporting 0 (cable unplugged): falls back to index 0, i.e.
  exactly the old behaviour.

Note

The same positional assumption exists for the GPU (SystemInfo.GetGpu()[0]),
which is the other half of #2915. Left alone here to keep this change focused.