fix: prevent concurrent LoadWithConfig calls from sharing working dir

[dgageot]

pkg/teamloader.LoadWithConfig previously mutated the caller's *config.RuntimeConfig directly — writing runConfig.WorkingDir to the value supplied by WithWorkingDir, then restoring the original in a defer. The API server holds a single shared sm.runConfig and passes it to LoadWithConfig for every session. Because sessions load concurrently, two simultaneous RunSession calls could observe each other's working directory inside that mutate-and-restore window. Toolsets (shell, filesystem, git, backgroundjobs, mcp, lsp) read runConfig.WorkingDir at creation time, so a session's tools could be rooted in another session's directory — a genuine isolation break, not just a cosmetic race.

When WithWorkingDir supplies a directory that differs from runConfig.WorkingDir, LoadWithConfig now clones the RuntimeConfig and works on the copy. The caller's config is never touched, so there is no window to race on. Callers that do not pass WithWorkingDir (CLI, MCP, A2A, ACP, and others) keep the existing behaviour, including the Models/Providers/ProviderRegistry write-back; pkg/server reads model info from LoadResult rather than from the config, so nothing depends on the write-back on that path.

TestLoadWithConfig_WithWorkingDirIsConcurrencySafe reproduces the bug: 8 concurrent loads share one RuntimeConfig, each with its own WithWorkingDir, and a recording toolset registry captures which directory each toolset was built with. Against the old code all 8 sessions got the same directory; the test passes cleanly with the fix, including under -race -count=3.