fix(desktop-windows): package Sentry's ms dependency

[tianmind-studio]

What changed and why

Fixes #10738 by declaring ms@2.1.3 as a direct Windows desktop runtime dependency. The packaged Sentry/debug chain reached ms, but electron-builder pruned it because it was only transitive, so the shipped app crashed before its main process could start.

This also adds a final-artifact probe that loads debug from app.asar/out/main/index.js with the packaged Electron binary and resolves ms. Both unsigned package scripts and the Azure-signed release path run the probe before an installer can be published.

Product invariants affected

none

How it was verified

• Before the dependency fix, the packaged Electron runtime exited 1 with Cannot find module 'ms'; the require stack ran through app.asar/node_modules/debug/src/common.js and app.asar/out/main/index.js.
• corepack pnpm@10 run build:unpack rebuilt the current branch and completed the new packaged-main probe successfully.
• The rebuilt ASAR contains node_modules/ms/index.js, license.md, and package.json.
• The rebuilt omi-windows.exe stayed alive for 12 seconds with an isolated user-data directory, initialized its renderer server, SQLite store, MCP and relay pipes, foreground monitor, and meeting monitor, and emitted no missing-ms error.
• corepack pnpm@10 test passed the full Windows desktop suite.
• corepack pnpm@10 run lint completed with 0 errors (735 existing repository warnings); focused ESLint and Prettier checks for the changed JavaScript files passed cleanly.
• actionlint .github/workflows/desktop_windows_release.yml passed.
• Local manifest preflight passed all 13 remaining selected checks and 29/29 runnable check-manifest-contract tests. The one excluded repository test is an existing Windows path-representation mismatch (/tmp/... from Git Bash versus C:\...\Temp\... in Python); the unmodified full check remains enabled in Linux CI.

Tests

• scripts/verify-packaged-main-runtime.test.mjs covers the successful packaged loader path, the original missing-ms failure, a missing success marker, rejection of lookalike executables, and secret-environment filtering.
• scripts/build-scripts-publish.test.mjs now proves that both unsigned and Azure-signed Windows release paths run the packaged-main probe after electron-builder.

Failure class (fixes)

Failure-Class: FC-runtime-image-boundary

New guards (only when adding a check or ratchet)

The final-artifact probe would have caught incident #10738 before its installer was published. It is not a shared source-only primitive because it requires a completed Windows electron-builder artifact and its packaged Electron binary; it is therefore attached to every existing Windows package and release path.

[Git-on-my-level]

Thanks for the focused Windows packaging fix — this is a good direction.

I reviewed the diff and ran the two focused desktop Windows tests in an isolated environment after installing dependencies with lifecycle scripts disabled:

• corepack pnpm@10 exec vitest run scripts/verify-packaged-main-runtime.test.mjs scripts/build-scripts-publish.test.mjs — 10 tests passed
• git diff --check origin/main...HEAD — clean

The direct ms@2.1.3 runtime dependency matches the Sentry/debug failure mode, and the new packaged-main probe is a useful regression guard: it runs after both unsigned and Azure-signed Windows packaging, strips the child process environment down to a small allowlist, requires the expected omi-windows.exe artifact, and fails closed if the packaged runtime cannot resolve ms.

Because this touches dependency metadata and the Windows release workflow/signing path, I’m leaving this as a positive maintainer signal rather than a formal approval. A human maintainer should still review the release-path implications before merge, but I did not find a blocking code issue in the changes I inspected.

---

by AI on behalf of David — if you need David’s attention urgently, please @Git-on-my-level and escalate with need human response.