[Bug] single-exe Web boot loses dsh.client metadata behind moduleFallback proxies

[Sujz13]

Summary

At commit 76fda729799fe9b3848dbe2c211d4b231032b81e (0.1.2-rc.1), the Linux x64 single-exe can serve the Web HTML but the browser stops at:

Failed to load plugins
client-modules: HTML did not preload @deepseek-ai/dsh-client-modules/client.js

This is reproducible on Node v24.19.0, after supplying the separate missing @deepseek-ai/dsh-session-title-llm runtime peer. It is not the Node 24.0-24.11 loader-shape issue discussed in #4968: current vendor/loader/src/internal.ts correctly detects the loader by module-job API shape, and the packaged carrier embeds a newer Node 24 runtime.

中文摘要：SEA 运行时为 profile 生成 moduleFallback 代理包后，client module registry 读取了代理包的 package.json，没有继续读取真实包的 dsh.client 元数据，导致浏览器启动批次缺失。

Environment

• Repository commit: 76fda729799fe9b3848dbe2c211d4b231032b81e
• Repository version: 0.1.2-rc.1
• Host: Ubuntu 20.04, Linux x64
• Build Node: v24.19.0
• pnpm: 11.7.0
• Target: node24-linux-x64
• Build profile: DSH_BUILD_CLIENT_PROFILE=official

Reproduction

pnpm install --frozen-lockfile
DSH_BUILD_CLIENT_PROFILE=official \
  pnpm exec tsx scripts/build-exe-for-python-sdk.ts \
  --targets=node24-linux-x64

./dist-exe/deepseek-harness-sdk-runtime-linux-x64 web --no-open

Open the printed token URL in a browser. A plain HTTP 200 or finding the package name in the HTML is not sufficient: after JavaScript executes, the boot surface reports the preload failure above.

Root cause

Packaged startup calls healProfilesModuleFallback(). For SEA, ensureModuleProxy() writes a real-filesystem proxy manifest resembling:

{
  "name": "@deepseek-ai/dsh-client-modules",
  "exports": { ".": "./entry-0.js" },
  "dsh": {
    "moduleFallback": {
      "targets": {
        ".": "file:///snapshot/.../@deepseek-ai/dsh-client-modules/lib/index.js"
      }
    }
  }
}

ClientModuleRegistry.resolveMeta() locates this proxy package and reads pkg.dsh.client. The proxy intentionally carries only dsh.moduleFallback, so the registry caches a negative client-package result instead of following targets["."] to the package inside the SEA VFS.

Expected behavior

Managed module-fallback proxies should preserve enough package identity for client discovery, and the generated HTML should preload the bootstrap client bundle plus the complete application batch.

Tested workaround

In packages/client/modules/src/index.ts, after reading a located manifest:

1. Detect a string dsh.moduleFallback.targets["."].
2. Resolve its nearest package with the expected package name.
3. Read dsh.client and exports from that real target manifest.

A focused regression test builds a proxy fixture and verifies that clientPath() and the boot graph point to the target package. After a full rebuild, Chromium observed the bootstrap bundle and a 46-entry application graph, and rendered the real Harness workspace UI.

The target manifest is inside the SEA VFS, so this fix also depends on making the patched filesystem API visible to ESM consumers; that is covered by the separate filesystem report.

Suggested upstream direction

Either follow the existing managed dsh.moduleFallback.targets metadata in client discovery, or copy the original package's client declaration into the generated proxy under an explicit contract. The former was validated locally and avoids duplicating client metadata.

Please also add a packaged dsh web browser smoke. Existing Python runtime scenarios exercise the SDK/JSON-RPC profile but do not execute the Web plugin boot graph.

Related but distinct: #4968 addresses the older Node 24 loader-signature classification problem.