Start Mcode workspace worker directly

[SaladDay]

Mcode workspace calls start the native worker directly, removing the intermediate Node launcher. The bridge reads its private profile once; ToolExecutor validates the canonical workspace and creates scratch at initialization, then uses that workspace for each worker's arguments and cwd. Invalid profiles fail initialization. Worker code, per-call input/output limits, cancellation and close settlement remain unchanged. Packaging no longer includes the launcher.

A controlled real File/Session View comparison used the same native worker and one workspace read per call, with three calls per variant at each delay. Each call dropped from 89 to 72 File RPCs and from two to one Node child starts. At 100 ms injected delay per File operation, median tool latency decreased from 9962.08 ms to 8210.23 ms (17.6%); at 0 ms, medians were 954.53 ms and 955.35 ms, showing no credible latency improvement. This measures local tool execution, not model/API latency or live provider qualification.

Validation:

• Package checks: 9 passed, 5 explicit artifact/prerequisite skips; JS and build-script syntax checks passed.
• Real native Docker cancellation and transport-close tests: 2 passed, no skips; detached Bash parent/child writers produced no later effects after settlement.
• Actual MCP bridge tool listing and native workspace read passed without model calls.
• Distribution tests: 30 passed, including stale companion rejection.
• Fresh independent blind review, including final test additions: no P0–P2 findings.

The standalone artifact checker stopped at its existing which rg prerequisite in the split agent-host image, which expects rg in the sandbox. That checker and the subsequent packaged large-output test are not reported as passed. No native rebuild or live validation was performed for this change; integrated packaging and qualification remain in the common build batch.

---

^{Need help on this PR? Tag @codesmith-bot with what you need. Autofix is disabled.}