Unify workspace path handling in tools

[meanaverage]

This PR unifies workspace path handling across the main tool surface so the agent behaves more consistently between host and Docker-style environments.

What was fixed:

• introduced a shared workspace-path normalizer in tsunami/tools/filesystem.py
• normalized common path variants seen in traces, including /app/workspace/..., /workspace/tsunami/workspace/..., /workspace/deliverables/..., and repo-root deliverables/...
• updated match_glob and match_grep to resolve directories through the shared resolver instead of raw Path(...).resolve()
• updated shell_exec so bad workspace roots inside command strings are normalized before execution and workdir is resolved through the same shared resolver
• updated python_exec so ARK_DIR, WORKSPACE, and DELIVERABLES are derived from the configured workspace_dir instead of hardcoded ark_dir/workspace
• updated swell_analyze to remove ad hoc Docker-specific fallback rewriting and use the shared resolver for both input directories and output paths
• updated generate_image so save_path uses the same resolver instead of its own partial workspace/app/workspace stripping logic
• updated project_init guidance so the model is told to use shell_exec with workdir='deliverables/' rather than absolute-path cd commands

Why this matters:

• before this change, different tools were interpreting the same project path in different ways
• that led to runs where one tool correctly found workspace/deliverables/ and the next tool looked in /workspace/tsunami/workspace/..., repo-root deliverables/..., or another non-existent variant
• the result was repeated false directory-not-found failures even when the project actually existed

Validation:

• python3 -m py_compile passed for all modified tool modules

Important caveat:

• this PR intentionally does not modify tsunami/tools/swell.py or tsunami/tools/swell_build.py
• those tools currently use workspace_dir.parent / project-root-style working directories, and that may be intentional to preserve broader repo visibility for eddy workers
• I left them unchanged and would like explicit review on whether they should remain repo-root scoped or also move to stricter workspace-relative semantics later

[meanaverage]

TL;DR

Introduced uniform workspace path resolver. Each tool had a different shape for path resolution, many didn't align with each other.

NOT TOUCHED IN THIS PR:

browser.py / vision_ground.py:
mostly accept user-provided absolute paths, which is a different category from workspace-relative tool confusion -- INTENTIONAL? not touched in this PR.

tsunami/tools/swell.py (line 69)
sets project_root = os.path.dirname(os.path.abspath(self.config.workspace_dir)), meaning it runs relative to the parent of the workspace, not the workspace itself. That is different again from the other tools.

tsunami/tools/swell_build.py (line 90)
uses Path(self.config.workspace_dir).parent as workdir, which shifts execution one directory above the workspace.

assuming may be intentional for scaffolding view? if not should be on uniform resolver

---

tsunami/tools/python_exec.py (line 74)
It hardcodes the repo workspace as ark_dir/workspace and ark_dir/workspace/deliverables and does os.chdir(ark_dir). It ignores self.config.workspace_dir, so host and Docker can drift immediately.

tsunami/tools/match.py (line 34)
match_glob resolves directory with Path(directory).expanduser().resolve() directly. It does not use the shared resolver from filesystem.py, so deliverables/..., workspace/..., and /workspace/... forms behave differently here.

tsunami/tools/match.py (line 77)
match_grep has the same issue as match_glob: direct Path(...).resolve(), no normalization via the canonical workspace path logic.

tsunami/tools/shell.py (line 115)
shell_exec resolves workdir relative to the repo root if it is not already absolute. That is inconsistent with the rest of the tool stack, which is supposed to operate relative to workspace_dir or the active project.

tsunami/tools/swell_analyze.py (line 50)
This tool contains custom fallback rewrites:

Path(self.config.workspace_dir).parent / stripped
directory.replace("/workspace/", "workspace/")
That is a separate normalization system, clearly Docker-shaped, and inconsistent with filesystem._resolve_path.
tsunami/tools/generate.py (line 48)
It strips only "workspace/" and "app/workspace/" before joining onto workspace_dir. That is another one-off normalization scheme, different from both filesystem.py and the broken /workspace/tsunami/... paths showing up in traces.

tsunami/tools/project_init.py (line 223)
The tool result teaches the model to run:
shell_exec 'cd {project_dir} && npx vite build'
That encourages absolute-path cd usage, which fights the idea of project-relative semantics and amplifies shell_exec’s inconsistent cwd handling.

tsunami/tools/filesystem.py (line 56)
This is the closest thing to a canonical resolver, but only the filesystem tools use it consistently. The inconsistency is less in this file and more that the rest of the tool stack bypasses it.

tsunami/tools/webdev.py (line 80)
webdev mostly uses Path(self.config.workspace_dir) correctly, but it still mixes in repo-root assumptions in places like asset download handling around tsunami/tools/webdev.py (line 582), where it computes ark_dir directly.

tsunami/tools/browser.py (line 475) and tsunami/tools/vision_ground.py (line 67)
These resolve absolute paths directly with Path(...).resolve(). That may be fine for user-provided files, but it is another path convention that does not flow through workspace-aware normalization.

[meanaverage]

further unification will allow reliable 'transient workspaces' via configurable option