fix(windows): resolve kernel path via %SystemRoot%

[SAY-5]

Fixes #287.

KernelVersion() called GetFileVersionInfo on a hardcoded C:\Windows\System32\ntoskrnl.exe, which fails with ERROR_FILE_NOT_FOUND on Windows hosts whose system drive is not C:\ (for example a server installed on W:\). The failure propagates through sysinfo.Host() and breaks Elastic Agent install/enroll on those hosts, as reported in the issue.

This PR resolves the kernel path through %SystemRoot% (falling back to %WINDIR%, then the historical C:\Windows default) and adds a t.Setenv-driven regression test covering each fallback step.

Local results:

• GOOS=windows go build ./... clean for amd64 and arm64.
• go run github.com/elastic/go-licenser@v0.4.2 -d clean.
• gofmt and go vet clean.
• The new TestKernelExePath table-test compiles and links cleanly on a Windows test binary (GOOS=windows go test -c).

I will add a .changelog/<pr>.txt entry once GitHub assigns the PR number.

[intxgo]

Since this PR tries to address totally stripped environment by fallback to "C:\Windows", this can be mitigated in a safer way.

is calling API an option GetSystemWindowsDirectory

or reading a registry HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SystemRoot

[SAY-5]

Pushed 7a745fb. Switched to reading HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SystemRoot via the registry (same pattern as os_windows.go). Env vars remain as fallback for stripped environments, hardcoded constant last resort.

[intxgo]

LGTM, but I have an opinion here. With the fix the behavior will be much better, however should the library decide on an arbitrary fallback const fallbackSystemRoot = C:\Windows ?

I think the client code could decide to do it, the library should return a "trusted" value or empty or error. Current behavior kind of still exhibit "half of" the original bug.

[andrewkroh]

I opened #289 to address the unrelated CI failure. That needs merged first to unblock the rest of the CI pipeline in this change.

[SAY-5]

Thanks, will rebase on top once #289 lands.