fix(deepseek-ivideo): pass preview owner guard to --import as a file URL

[Shyboy0499]

Summary

On Windows the iVideo view never starts: every plugin-owned HyperFrames preview child process dies at boot with ERR_UNSUPPORTED_ESM_URL_SCHEME.

VideoRuntimeManager resolves the preview owner guard to a native path and hands it to node --import, which accepts only a URL or a bare specifier. On Windows C:\...\preview-owner-guard.js parses as protocol c: and the ESM loader refuses it. POSIX tolerates native paths, which is why macOS and Linux are unaffected.

Fixes #3
Fixes #4

Change

• resolvePreviewOwnerGuardUrl() returns the guard as a file:// URL, mirroring the existing resolveHyperframesCli() helper directly above it.
• The field is renamed ownerGuardPath → ownerGuardUrl so its representation is stated at every use site. Its only consumer is the --import argument.
• cliPath is deliberately left as a native path: it is passed as a positional argument, where Node expects a path rather than a URL. Converting it too would be incorrect.
• A regression test asserts the specifier's protocol is file:, that it round-trips to a real file, and that node --import accepts it as produced.

Verification

Run in source/plugins/deepseek-ivideo on macOS (darwin 25.6.0), Node v22.21.1:

Command	Result
pnpm install --frozen-lockfile	ok
npx tsc -p tsconfig.json --noEmit	13 errors, identical to the pre-change baseline; none at the changed lines
node --check test/runtime.test.mjs	ok

I could not run pnpm test, or get a clean pnpm check, in this repository — for reasons unrelated to this change:

• build:runtime requires vendor/hyperframes and bun, neither of which is mirrored here.
• source/ carries upstream-relative imports (../../../../packages/video-studio/..., ../../studio-host/...) that do not resolve against this repository's source/shared/... layout, producing 13 type errors on a clean checkout. Filed separately as source/ cannot be type-checked or built: sync relocates packages/* to source/shared/* without rewriting relative imports #6.

So I verified the behaviour directly instead. The assertion that catches the bug is pure URL parsing and is platform-independent:

Specifier produced by each implementation:
  OLD (native path) : /tmp/.../preview-owner-guard.js
  NEW (file:// URL) : file:///tmp/.../preview-owner-guard.js

POSIX (this machine):
  OLD impl -> new test FAILS (TypeError: Invalid URL)
  NEW impl -> new test PASSES

Windows path shapes:
  new URL("C:\\...\\preview-owner-guard.js").protocol       === "c:"    -> assertion rejects
  new URL("file:///C:/.../preview-owner-guard.js").protocol === "file:" -> assertion accepts

Node ESM loader:
  node --import "c:/..." throws ERR_UNSUPPORTED_ESM_URL_SCHEME (protocol 'c:')

The last line reproduces, on macOS, the exact error class both issue reports hit on Windows.

I do not have a Windows machine and have not confirmed the end-to-end fix on Windows firsthand. The reporter of #4 states they verified the equivalent one-line patch locally on Windows 10.0.26200 with Node v24.13.0.

I also confirmed the defect is still present in the currently published bundle (packages/deepseek-ivideo/lib/runtime-BDSMUY5d.js, v0.5.0 — ownerGuardPath = fileURLToPath(...), no pathToFileURL anywhere), so this is not already fixed upstream.

Notes

• Only source/ is touched; no generated file under packages/ is edited.
• Prepared with AI assistance (Claude); the reasoning, verification and results above were reviewed before submission.