fix(teamloader): propagate session working dir to toolsets

[trungutt]

Why

teamloader.LoadWithConfig accepts a per-session working directory via WithWorkingDir, but the value was only used to resolve parentDir locally — it was never written back onto runConfig.

Toolsets read runConfig.WorkingDir directly at construction time:

// pkg/tools/builtin/shell/shell.go
workingDir: runConfig.WorkingDir

So the option was silently dropped for every tool: shell, filesystem, and any other toolset that keys off runConfig.WorkingDir ran in the docker-agent process CWD instead of the session's directory.

Symptoms in a long-lived docker-agent serve api process: shell and filesystem calls in a session created with working_dir: /home/user/project end up operating on the server's own CWD (e.g. wherever the daemon was launched from), not /home/user/project.

Regression

65bffd71f ("decouple WorkingDir from RuntimeConfig in SessionManager") moved the WorkingDir write-back into a local variable inside the loader while keeping the neighbouring writes (Models, Providers, ProviderRegistry) in place. This restores the write-back on the merged workingDir local so it reaches the toolsets, without reintroducing the previous runConfig.Clone() at the call site.

[docker-agent]

Assessment: 🟡 NEEDS ATTENTION

[docker-agent]

[MEDIUM] Conditional WorkingDir mutation may produce stale value on repeated Load calls

runConfig is a shared pointer and LoadWithConfig already mutates it in-place for Models, Providers, and ProviderRegistry — so the pattern itself is intentional. However, this new mutation has a subtly different character: the value written is cmp.Or(loadOpts.workingDir, runConfig.WorkingDir), which is a conditional merge of a per-call option into the shared struct.

Trigger path: a caller that reuses the same *RuntimeConfig across multiple Load calls with different WithWorkingDir options:

// First call: WithWorkingDir("/tmp/session-1")
Load(ctx, src, runConfig, WithWorkingDir("/tmp/session-1"))
// → runConfig.WorkingDir is now "/tmp/session-1"

// Second call: no WithWorkingDir → loadOpts.workingDir == ""
Load(ctx, src, runConfig)
// → cmp.Or("", "/tmp/session-1") = "/tmp/session-1"  ← stale leak

The second call inherits the first session's directory instead of the daemon's original CWD, which is the opposite of the symptom this PR aims to fix.

Mitigation: if runConfig is expected to be reused across sessions (e.g. in docker-agent serve api), consider restoring WorkingDir after the call, or accepting only a fresh runConfig per session. The current tests do not exercise this reuse pattern with differing WithWorkingDir values, so the scenario is untested.

[trungutt]

Good catch — the merged value would leak into a subsequent no-WithWorkingDir call on the same *RuntimeConfig.

Fixed in bfd2a0f by saving runConfig.WorkingDir at entry and defer-restoring it at exit, so toolsets see the merged directory during the call while the shared runConfig is left as the caller found it. Added TestLoadWithConfig_WithWorkingDirDoesNotLeak to pin the two-sequential-Load scenario.

[docker-agent]

Perfect fix — the defer-restore pattern ensures runConfig.WorkingDir is visible to toolsets during the call while leaving the shared struct exactly as the caller provided it. The test covers the precise two-sequential-Load scenario where the stale leak would have occurred.

Validated that the defer runs on both normal and error paths, so even a mid-load failure won't leak the merged value. Thanks for the thorough follow-up!

[docker-agent]

Assessment: 🟢 APPROVE

The fix correctly restores the missing runConfig.WorkingDir = workingDir write-back that was lost in commit 65bffd71. The ordering (before parentDir resolution and toolset construction at line 240+) is right, and cmp.Or(loadOpts.workingDir, runConfig.WorkingDir) correctly preserves a pre-set WorkingDir when WithWorkingDir is not explicitly passed.

Mutation safety: The in-place mutation pattern is consistent with the pre-existing writes to runConfig.Models, runConfig.Providers, and runConfig.ProviderRegistry already present in this function. In the recursive loadExternalAgent path, WithWorkingDir is not propagated to sub-load opts, so cmp.Or("", runConfig.WorkingDir) is a no-op write-back. The session manager creates a fresh runConfig per session, ruling out cross-session pollution.

Minor note (no action required): There's no test that exercises the WithWorkingDir → runConfig.WorkingDir propagation path directly; existing tests set runConfig.WorkingDir directly. A regression test calling LoadWithConfig with WithWorkingDir and asserting the resulting runConfig.WorkingDir would guard against re-introducing the original regression from 65bffd71.