fix(coding-agent): preserve saved cwd on daemon resume

[aoright]

Summary

• Preserve an omitted cwd when the supervisor forwards a saved-session create to its worker, so SessionManager.openAsync uses the cwd recorded in the session header.
• Keep the merged cwd separately for the worker process launch, preserving existing spawn behavior without turning it into a session override.
• Add a process-level A/B regression that starts the daemon in project A, resumes a persisted session from project B, and asserts the worker reports B.

This is a backward-compatible behavior fix; the daemon wire shape and schema are unchanged.

Testing

• npx tsx ../../node_modules/vitest/dist/cli.js --run test/suite/regressions/1124-resume-recorded-cwd.test.ts
• npm run check

Fixes #1124

Note

Fix resumed daemon sessions to use saved working directory instead of daemon launch directory

When resuming a session from a sessionPath, the spawned worker process was starting in the daemon's launch directory instead of the session's recorded cwd. The fix introduces prepareWorkerLaunch in daemon-supervisor.ts, which strips cwd from the config for resumed sessions and passes it directly to the spawn options instead. A regression test in 1124-resume-recorded-cwd.test.ts verifies the correct directory is used.

^{Macroscope summarized 88eb3be.}

[MingTeer]

Verified the fix end-to-end on our fork (17 commits behind upstream/main). Traced the full path and it closes the loop:

• Bug: the supervisor merges defaultSessionConfig.cwd into the forwarded command.config, so the worker's cwdOverride = command.config?.cwd is always set, and SessionManager.openAsync(sessionPath, dir, cwdOverride) lets it override the header cwd. Resumed sessions silently run in the daemon launch directory.
• Fix: deleting config.cwd when sessionPath is set and the client sent no explicit cwd makes cwdOverride undefined, so the header cwd wins; runtime cwd then comes from sessionManager.getCwd(). The worker-side if (!config.cwd) throw is unaffected since the worker re-merges with its own defaults. mergeAgentSessionRuntimeConfig always returns a fresh object, so the delete can't pollute shared config. Scope is correctly limited to resume-without-explicit-cwd; new sessions and --cwd behave as before.
• A/B check: the regression test fails against the pre-fix daemon-supervisor.ts and passes with the fix.

One non-blocking note on the test: it spreads ...process.env into the spawned supervisor. When run from inside a prime-agent session (e.g. via the IPython tool or a tmux pane), PRIME_AGENT_INTERNAL_DAEMON_WORKER and friends leak in, the spawned process identifies as a worker instead of a supervisor, and the handshake times out. Scrubbing PRIME_AGENT_INTERNAL_* from the test env would make it more portable.

We cherry-picked this onto our fork because the silent wrong-directory behavior writes into the wrong repository. Hope it lands upstream.