net: fix MIB_IF_ROW2 layout on Windows 386

[zhangli091011]

Fixes #1865.

Windows aligns the ULONG64 fields in MIB_IF_ROW2 to an 8-byte boundary. Go only gives uint64 4-byte alignment on 386, which caused TransmitLinkSpeed and every following network counter to be read four bytes early.

This adds four bytes of explicit padding for Windows 386 while retaining the existing layout on other Windows architectures. A deterministic 386 regression test verifies the TransmitLinkSpeed offset and total structure size.

Verification

• Windows amd64 and 386 go test ./net -count=1 with CI behavior enabled
• Windows amd64 and 386 focused network tests
• Windows amd64 and 386 build and vet
• git diff --check

AI disclosure

OpenCode using myself/gpt-5.6-sol assisted with issue investigation, implementation, and test preparation. I reviewed the ABI rationale, source changes, and verification results.

[zhangli091011]

Would you have a chance to review this PR when convenient? CI is green. Thank you!

[shirou]

Thanks for tracking this down — the analysis is correct, and I verified that TransmitLinkSpeed lands at offset 1192 with a total size of 1352 on 386 with this padding, matching amd64.

One suggestion: since unsafe.Alignof is a constant expression and net_windows.go already imports unsafe, the padding can be derived directly, without the two build-tagged files:

const (
      maxStringSize        = 256
      maxPhysAddressLength = 32
      // Windows aligns ULONG64 to 8 bytes, but Go only gives uint64 4-byte
      // alignment on 32-bit architectures, so pad ConnectionType up to the
      // next 8-byte boundary there.
      // https://learn.microsoft.com/en-us/windows/win32/api/netioapi/ns-netioapi-mib_if_row2
      pad0for64_4for32 = (8 - unsafe.Alignof(uint64(0))) % 8
)

This yields 4 on windows/386 and 0 on windows/amd64 and windows/arm64 (same as today), and it also stays correct for any other 32-bit Windows port, which !386 would miss.

Would you mind giving it a try?