feat(client): report TAP interface identity

Resolve the opened TAP adapter's NetCfgInstanceId to its Windows interface
index and LUID during startup, then print those values with the existing TAP
MAC/MTU diagnostics. This makes the interface identity visible before the next
metric-setting slice uses it for route protection.

The lookup failure is treated as startup failure because an opened TAP adapter
that cannot be resolved as a Windows network interface is not a good candidate
for metric or route management.

Verification note: I attempted to check `lanparty-client-win` for
`x86_64-pc-windows-msvc`, but this host still lacks the Windows C headers
needed by `ring`; the build stops at `assert.h` before the binary crate can be
typechecked for Windows.

Test Plan:
- cargo fmt --check
- cargo test --workspace
- cargo clippy --workspace --all-targets -- -D warnings
- cargo check -p lanparty-client-route --target x86_64-pc-windows-msvc
- cargo clippy -p lanparty-client-route --target x86_64-pc-windows-msvc --all-targets -- -D warnings
- git diff --check

Refs: PLAN.md

README.md

@@ -137,5 +137,6 @@ and then bridges Ethernet frames between the relay and the first TAP-Windows6
 adapter until shutdown.
 `--virtual-mac` can still override the stored identity for manual testing. On
 Windows it marks the TAP media connected and reports the driver MAC/MTU before
-forwarding frames. Default-route takeover neutralization and automatic TAP
-MAC/MTU configuration are not wired yet.
+forwarding frames, along with the TAP interface index/LUID. Default-route
+takeover neutralization and automatic TAP MAC/MTU configuration are not wired
+yet.