fix(vite): resolve Solid runtime dev builds from package exports - #11628

PR Checklist

• The PR title follows our guidelines: https://github.com/NativeScript/NativeScript/blob/master/tools/notes/CONTRIBUTING.md#commit-messages.
• There is an issue for the bug/feature this PR is for. To avoid wasting your time, it's best to open a suggestion issue first and wait for approval before working on it.
• You have signed the CLA.
• All existing tests are passing: https://github.com/NativeScript/NativeScript/blob/master/tools/notes/DevelopmentWorkflow.md#unit-testing.
• Tests for the changes are included - https://github.com/NativeScript/NativeScript/blob/master/tools/notes/WritingUnitTests.md.

What is the current behavior?

With solid-js / @solidjs/* 2.0.0-rc.19, an HMR dev session fails at boot:

[ns-entry] deterministic dev session bootstrap failed TypeError: Cannot read properties of undefined (reading 'guideUrl')
    at installConsoleFooter (http://…/ns/m/node_modules/solid-js/dist/solid.dev.js:1725:26)

Two causes, both from Solid's rc.19 package layout:

1. @solidjs/signals resolves to its prod build. The deps bundle, its root-URL shims, and the bare-import rewrite all resolve packages without the development condition, so @solidjs/signals lands on dist/prod/index.js, where DEV is undefined. rc.19's solid.dev.js reads DEV.guideUrl at module load. (rc.0 also paired with prod signals, but nothing read DEV at load.)
2. solid-js/dist/dev.js no longer exists. The canonical solid-js URL is hard-coded in rewrite-imports, the deps bundle (seed + routing), the Solid strategy's import map, and configuration/solid.ts. rc.19 renamed the file to dist/solid.dev.js, so these URLs 404, and they diverge from the solid.dev.js URL other importers reach, which would load a second Solid instance.

What is the new behavior?

helpers/solid-runtime.ts resolves the dev build of each Solid runtime package root (solid-js, @solidjs/signals, @solidjs/universal, @solidjs/web) from that package's own exports map, preferring targets under development. All Solid pin sites use it:

• rewrite-imports: bare runtime roots rewrite to /ns/m/node_modules/<pkg>/<dev entry>.
• deps-bundle: the routing plugin, the vendor seed, recorded boot paths (an old recording containing /ns/m/node_modules/@solidjs/signals no longer bundles prod), and package-root URL → shim lookup all go through one resolveDepsSpecToFile.
• Solid strategy importMapEntries: solid-js maps to the resolved dev URL.
• configuration/solid.ts: in dev, aliases the runtime packages to their dev builds. Aliases are now anchored, so subpaths like solid-js/internal reach the exports map instead of being prefix-matched to …/dist/dev.js/internal.

Compatibility:

• solid-js 1.x and 2.0.0-rc.0 still resolve to dist/dev.js. The exports maps of all three layouts are covered in solid-runtime.spec.ts.
• When the exports map names no dev build, solid-js falls back to the legacy dist/dev.js.
• The development condition is intentionally not enabled globally (see the conditions note in hmr/shared/vendor/manifest.ts about isServer stubs). Other flavors and non-Solid packages are unchanged.

Verified against an rc.19 app:

• The deps bundle registers only solid.dev.js, signals/dist/dev.js, universal.dev.js and solid-js/dist/internal.js, with no prod Solid files.
• /ns/m/node_modules/{solid-js,@solidjs/signals,@solidjs/universal} serve shims of those dev builds.
• The import map's solid-js points at dist/solid.dev.js, and app modules import the same URL. This holds with and without app-level Solid aliases.
• The full packages/vite suite passes (166 files / 1943 tests), and the new deps-bundle test fails on main.