fix(memory-core): read the win32 process start identity through kernel32, not PowerShell

The Windows start-identity probe spawned `powershell.exe Get-Process` under a
2 s execFile budget on every lookup. On a loaded (or merely cold) runner
PowerShell start-up alone crosses that budget, the probe is killed and reports
null, and a null own identity is deliberately never memoized, so every lock
record creation paid the full 2 s. The two-process takeover test runs nineteen
sequential commits in its survivor and could not fit that tax into 30 s.

kernel32 OpenProcess + GetProcessTimes answers the same question in-process in
microseconds, for our own pid and for foreign owners alike; the new scheme
`win32-creation-filetime` stays incomparable with the old `win32-creation-date`
records, so a mixed-version window keeps every live owner. PowerShell remains
only as the fallback for a runtime without bun:ffi. Foreign pids stay uncached.

Part of #8294