What

Repair bundled runtime plugin dependency resolution so packaged builds keep dingtalk-stream for dingtalk-connector without regressing silk-wasm for openclaw-qqbot.

Why

PR #1001 fixed qqbot by preferring a plugin package's local node_modules, but that breaks pnpm-installed plugins like dingtalk-connector whose package-local node_modules only contains .bin. Packaged Windows builds could then ship a dingtalk-connector plugin without dingtalk-stream, causing Cannot find module 'dingtalk-stream' after gateway restarts.

How

• Teach bundle-runtime-plugins to prefer package-local node_modules only when it contains real dependencies, otherwise fall back to the pnpm virtual-store dependency root.
• Add a regression test covering both layouts: qqbot-style local dependencies and dingtalk-style pnpm virtual-store dependencies.
• Expand controller sidecar and packaged artifact validation so both openclaw-qqbot/silk-wasm and dingtalk-connector/dingtalk-stream must exist.

Affected areas

• Desktop app (Electron shell)
• Controller (backend / API)
• Web dashboard (React UI)
• OpenClaw runtime
• Skills
• Shared schemas / packages
• Build / CI / Tooling

Checklist

• pnpm typecheck passes
• pnpm lint passes
• pnpm test passes
• pnpm generate-types run (if API routes/schemas changed)
• No credentials or tokens in code or logs
• No any types introduced (use unknown with narrowing)

Notes for reviewers

• Targeted tests run: pnpm --filter @nexu/controller exec vitest run tests/bundle-runtime-plugins.test.ts tests/openclaw-runtime-plugin-writer.test.ts.
• I also reran pnpm --filter @nexu/controller bundle-runtime-plugins and pnpm --filter @nexu/desktop prepare:controller-sidecar and confirmed both packaged plugin trees now contain dingtalk-stream and silk-wasm.