feat: react-native-windows support

[StasDoskalenko]

Description

Adds React Native Windows as a supported platform. A project can run its harness
suite against a deployed RNW app by adding @react-native-harness/platform-windows
and a windowsPlatform() runner to rn-harness.config.mjs. No custom runner
script, no metro.config.js changes, no patches.

Four things were missing:

1. Host support. Loading an ESM rn-harness.config.mjs failed when the
   harness process runs on Windows: the config reader passed a bare absolute
   path to dynamic import(), which Node only accepts as a file:// URL.
   getDeviceDescriptor() also threw for Platform.OS === 'windows', which
   aborts the bridge handshake.

2. Out-of-tree platform Metro wiring. The harness loads Metro config with a
   bare Metro.loadConfig, so it skips the wiring
   @react-native/community-cli-plugin installs for out-of-tree platforms: the
   react-native to react-native-windows resolver redirect, the platform's
   InitializeCore, and the extra resolver.platforms entries. Without them a
   windows bundle cannot resolve react-native/... and the instance redboxes
   before HMRClient is registered.

3. The platform package. There was no @react-native-harness/platform-windows.

4. The GitHub Action. ${{ github.action_path }} is a native path, passed
   unquoted to node inside shell: bash steps, so on a Windows runner bash
   ate the backslashes (D:\a\_actions became D:a_actions) and every helper
   script failed to load.

What changed

• @react-native-harness/config: wrap the .mjs config path in
  pathToFileURL() before import(). No behavior change on POSIX.
• @react-native-harness/runtime and @react-native-harness/bridge: add a
  windows case to getDeviceDescriptor() and 'windows' to the
  DeviceDescriptor platform union (declared in both packages).
• @react-native-harness/bundler-metro: read the RN CLI config
  (@react-native-community/cli-config, resolved from the project, optional
  peer dependency) and, when a platform declares an npmPackageName, apply the
  same wiring loadMetroConfig does. Gated on that check, so iOS and Android
  runs produce a byte-identical Metro config.
• New @react-native-harness/platform-windows, modeled on platform-vega.
  windowsPlatform({ name, packageName, appId?, processName? }). The runner
  resolves the package family name from the manifest identity name with
  Get-AppxPackage, shell-activates the app by its AUMID, confirms the process
  started, then polls it and emits app_exited when it goes away.
• @react-native-harness/platforms: add WindowsAppLaunchOptions.
• The composite action: quote every ${{ github.action_path }} interpolation,
  exempt the windows platform from the "app input required" check like web,
  and derive HARNESS_PROJECT_ROOT with pwd -W so hook subprocesses get a
  native path under Git Bash. Same quoting fix in the deprecated per-platform
  sub-actions.
• Docs: a Windows platform guide, a "Windows in CI" section in the CI/CD guide,
  and Windows in the configuration guide's platform list.

Two incidental fixes surfaced while running the suite on a Windows host:

• resource-lock.ts: a heartbeat refresh whose write threw (owner file racing a
  release, or a transient FS error) escaped the setInterval callback as an
  unhandled rejection. It is now swallowed, which matches the existing behavior
  for a missed refresh (the lock goes stale and is reclaimed).
• RunnerSchema: a bare z.object() stripped the getResourceLockKey every
  platform factory sets, so the session always fell back to
  <platformId>:<runnerName>. Adding it to the schema means runs against
  different devices of the same platform no longer serialize.

A few test path assertions assumed POSIX separators and only failed when the
suite runs from Windows; those were fixed too.

Related Issue

Context

The runner contract (HarnessPlatform, HarnessPlatformRunnerFactory) is
public, and platform-vega already shows the shape of an out-of-tree platform
package, so platform-windows follows that pattern.

The Metro change is the one that touches a shared path. It is deliberately
gated: nothing happens unless the RN CLI config reports an out-of-tree platform,
and there is a regression test asserting the Metro config is unchanged in that
case. @react-native-community/cli-config is resolved from the project rather
than pinned as a hard dependency, and declared as an optional peer, so projects
without it are unaffected.

This was developed and tested with Nitromodules fork I'm working on https://github.com/StasDoskalenko/nitro. It can land as one
PR or as a stack, whichever is easier to review.

Testing

Unit tests added for each piece: the config reader loading .mjs / .js /
.json configs, getDeviceDescriptor per platform, the CLI-config parsing and
resolver redirect in bundler-metro (plus a regression test that the config is
byte-identical with no out-of-tree platform), the windows runner (AUMID
assembly, not-deployed, process-never-started, app_exited, abort semantics),
and the getResourceLockKey schema change.

End to end: ran react-native-harness --harnessRunner windows against a
deployed RNW app (mrousavy/nitro's example) at each step. The final state, with
the composite action doing the run, passes on a stock windows-2025 GitHub
runner:

Load React Native Harness configuration   ok
Run E2E tests: react-native-harness --harnessRunner windows windows-smoke
  HARNESS Runner windows ready
  Test Suites: 1 passed, 1 total
  Tests:       2 passed, 2 total

Full suite (nx run-many -t test) is green on both Linux and Windows.

[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]

unfortunately windows runners require ""

[V3RON]

Hey @StasDoskalenko!
Thanks for the contribution. I've briefly gone through it and started wondering if we should somehow move the Metro config augmentations to the platform packages so that when somebody uses Windows, only the changes related to it are applied.

We could expose an enhanceMetroConfig method that would be called when a platform declares one, passing it the Metro config produced by Harness and allowing the platform to make additional changes.

If any new platform comes with different Metro requirements, it can simply make the necessary changes itself. There would be no need to reach out to bundler-metro again.

WDYT?

[StasDoskalenko]

@V3RON hey 👋

Thanks for taking a look! I actually think that would be a better shape than what I've got. Pushing the Metro tweaks into the platform package means bundler-metro doesn't need to know anything about platforms, and it lets us drop the @react-native-community/cli-config lookup completely, since a platform package already knows its own npm name (react-native-windows and friends). If macOS or anything else shows up later with its own quirks, it just handles them itself.

Couple of things to consider:

The enhancer probably can't be a plain function hanging off the platform object. RunnerSchema is a z.object(), so it strips anything it doesn't know about during config parsing, and the function would be gone before the session ever sees it. That's the same thing that caught getResourceLockKey. Feels like the cleanest fit is to follow how runner and cli already work: a metroConfigEnhancer string pointing at a module, and withRnHarness imports it and calls it with the patched config plus a bit of context (projectRoot mainly, so it can resolve the platform's InitializeCore).

The other bit is that the enhancer needs to know which runner you're on. Good news is the session already has the resolved runner right before it spins up Metro, so it's just a matter of passing it down into withRnHarness. Nice side effect: the enhancer would only run for the runner you actually selected, instead of my current version which applies the wiring for every out-of-tree platform it can find.

The resolver redirect and the resolver.platforms additions move over pretty much untouched. getModulesRunBeforeMainModule is the only one that needs a little care so the enhancer composes with whatever's already there, but since Metro only keeps run-before modules that are actually in the graph, it stays a no-op for iOS and Android anyway.

Happy to rework it along these lines. Want it in this PR, or should we land the rest first and do it as a follow-up?

[V3RON]

Sounds good! Let's make it like this: metroConfigEnhancer is a path to a module that is then imported when composing the Metro config and evaluated in the context of the project 🙆‍♂️

[StasDoskalenko]

@V3RON, that makes sense. The PR is here #190 👍
After we merge that pr, I'll rebase my fork and update this PR.