fix(cli): invoke Rspeedy without Windows shims

[Huxpro]

Summary

• resolve @lynx-js/rspeedy through its exported package.json and validated bin.rspeedy metadata
• invoke the resolved JavaScript bin with process.execPath for both build and dev
• preserve separate argument boundaries and shell: false, including when package or app paths contain spaces
• leave generic runCommand callers such as adb, Gradle, and iOS tooling shell-free

Root cause

On Windows, npm and pnpm expose rspeedy through a .cmd batch shim. Node's child_process.spawn() cannot execute that shim directly with shell: false, so Sparkling failed with spawn rspeedy ENOENT.

Rather than enabling a shell for all Windows commands, this change bypasses the platform shim: it resolves Rspeedy's declared JavaScript bin from package metadata and launches it with the current Node executable. Build and dev share the same resolver, while the existing dev restart and signal lifecycle remains unchanged.

Tests

• focused resolver and build/dev invocation tests, including package and app paths containing spaces
• config-loading precedence test for dev
• regression test that generic runCommand remains shell: false
• full sparkling-app-cli Jest suite: 12 suites, 71 tests
• package build
• Jest tsconfig typecheck
• diff whitespace checks
• independently reviewed compiled resolver and real resolved Rspeedy JS bin execution (--help)

Residual risk

The Windows-shaped resolution and invocation behavior is covered deterministically, but the patch has not been run end-to-end on a native Windows host.

Fixes #63

This supersedes the remaining Windows Rspeedy launch portion of #73. It intentionally does not redo the ESM loader path fix, which is already present on main.