feat: support running the harness on a Windows host

[StasDoskalenko]

What is this?

Two fixes that let the Harness host process and runtime handle React Native
Windows. Neither adds a Windows platform runner yet — they remove the host-side
assumptions that make an RNW app fail before any platform-specific work could
run.

• @react-native-harness/config — loading an ESM rn-harness.config.mjs
  fails on a Windows host. The reader passes a bare absolute path to dynamic
  import(), and Node only accepts a file:// URL there; on Windows the drive
  letter is parsed as a URL scheme and rejected with
  ERR_UNSUPPORTED_ESM_URL_SCHEME.
• @react-native-harness/runtime / @react-native-harness/bridge —
  getDeviceDescriptor() throws Unsupported platform for
  Platform.OS === 'windows', which aborts the bridge handshake during
  reportReady.

How does it work?

• The reader now wraps the resolved config path in pathToFileURL() before
  import(). This is a no-op-shaped transform on POSIX (/abs →
  file:///abs), so the path is unchanged in behavior there and simply becomes
  valid on Windows.
• getDeviceDescriptor() gains a windows branch that reports
  platform: 'windows' with an osVersion read from Platform.constants
  (falling back to ''), and the DeviceDescriptor platform union — declared
  in both runtime and bridge — includes 'windows'.

Both packages gain unit coverage: the config reader is exercised loading
.mjs / .js / .json configs and walking up to a parent directory, and
getDeviceDescriptor now has a test per platform including windows.

Why is this useful?

RNW is a first-class out-of-tree React Native platform. Today, running Harness
against an RNW app requires patching both of these in node_modules. Folding
them in removes the patches and is the smallest first step toward first-class
Windows support; the platform runner, out-of-tree Metro wiring, and CI are
separate follow-ups.

---

Note: the Harness test suite has some pre-existing POSIX-path assumptions in
@react-native-harness/bundler-metro tests (e.g. paths.test.ts passes a
non-absolute-on-Windows path) that fail when the suite runs on a Windows host.
Those are untouched here and out of scope; CI runs on ubuntu-latest and is
unaffected.

[vercel]

@StasDoskalenko is attempting to deploy a commit to the Callstack Team on Vercel.

A member of the Team first needs to authorize it.

[StasDoskalenko]

Closed — this was opened against the wrong repo. It belongs on my fork for now.