Derive RSC recovery version from client compatibility graph

[agcty]

Stacked on remix-run#15032's conservative versioned RSC recovery baseline.

This follow-up replaces the production random RSC recovery token with a deterministic compatibility hash derived from @vitejs/plugin-rsc's compiler-owned reference metadata instead of route/source scanning. The hash includes:

• core React/RSC/React Router/Vite runtime package versions
• Vite base path, because it affects client asset resolution
• client reference identity plus rendered exports from plugin-rsc's clientReferenceMetaMap
• server reference identity plus export names from plugin-rsc's serverReferenceMetaMap
• a build salt only when the RSC bundle uses plugin-rsc's generated server-action encryption key, because that key is not currently exposed through the compiler API

The goal is Jacob-style compatibility recovery: server-only RSC changes and client implementation-only changes can keep the same recovery version, while client/server reference ABI changes still force document recovery. Encrypted server-action builds remain conservative until plugin-rsc exposes stable encryption-key identity or downstream apps provide one through a first-class API.

Validation:

• pnpm test -- packages/react-router-dev/tests/rsc-compatibility-version-test.ts packages/react-router/tests/rsc/browser-test.ts packages/react-router/tests/rsc/server-test.ts --runInBand
• pnpm --filter @react-router/dev typecheck
• pnpm --filter @react-router/dev build
• pnpm exec eslint packages/react-router-dev/vite/rsc/compatibility-version.ts packages/react-router-dev/vite/rsc/plugin.ts packages/react-router-dev/tests/rsc-compatibility-version-test.ts
• pnpm changes:validate
• git diff --check
• pnpm --filter @react-router/fs-routes build, then pnpm --filter integration-rsc-vite-framework build and verified the emitted server bundle contains a concrete compatibility version with no placeholder remaining

[agcty]

Closing this in favor of the lower-level plugin-rsc primitive here:
vitejs/vite-plugin-react#1223

This PR was useful as the exploration path, but after working through the edge cases it became clear that React Router should not reconstruct RSC compatibility from framework-side state. @vitejs/plugin-rsc owns the authoritative build/RSC data: client references, rendered exports, server references, final assets manifest, output bundles, and server-action encryption identity.

The better shape is:

• plugin-rsc exposes a compiler/build compatibility manifest
• React Router consumes that manifest and composes it with any React Router-specific deployment or routing state
• React Router owns the recovery behavior

So the next React Router PR should be an integration with virtual:vite-rsc/compatibility-manifest, not this framework-side derivation.