harness: ProjectAwareOverlay/projectWritable design has structural inconsistencies (dual-root routing)

## Summary

This is a **design discussion**, not a bug report. `LocalFilesystemSpec.projectWritable(true)` (backed by `ProjectAwareOverlay`) routes writes to the project directory for non-workspace paths so code-generation agents can write directly into the user's repo. The goal is sound, but the mechanism couples several conflicting responsibilities into one abstraction, producing structural inconsistencies that no single-layer patch can fully resolve.

## Current design

- Write (default) -> workspace (upper); read -> workspace first, project fallback (standard overlay).
- With `projectWritable(true)`, non-metadata writes are routed to the project directory; metadata (`MEMORY.md`, `memory/`, `agents/`, `skills/`, ...) stays in the workspace.
- Shell `execute()` runs `sh -c` with `cwd = project` on the real host, bypassing the overlay entirely.
- Absolute paths under the workspace root must be stripped of the workspace prefix to be consistent (see recent fixes).

## Problems

1. **Read/write divergence (ghost copies).** With `projectWritable`, a non-metadata path is written to `project`, but read/search still prefer `workspace` first. If a stale copy of the same file exists in the workspace (e.g. from before the mode was enabled), `read` returns the stale copy while `edit/write` modify the project file — the same logical file points at two physical locations.
2. **Name-prefix routing is a weak signal.** `WORKSPACE_PREFIXES` is a flat, hard-coded string set. Real projects routinely contain entries like `AGENTS.md`, `rules/`, `plans/`, `knowledge/`, and those collide with the classifier.
3. **Shell and file tools expose two inconsistent world views.** File tools resolve relative paths against workspace + project overlay; shell resolves them against the project root. `echo x >> MEMORY.md` lands in the project while `write_file MEMORY.md` lands in the workspace; `cat AGENTS.md` shows the project version while `read` may show the workspace copy. `ls`/`grep`/`glob` merge two layers, but shell sees one.
4. **Absolute paths are special-cased.** Consistent behaviour requires stripping the workspace prefix, which is a symptom of the dual-root design rather than a first-class path model.

## Reference: how mainstream coding agents do it

opencode and Claude Code use a **single root** (the project working directory):

- File operations (read/write/edit/bash) all resolve against one root; writes land in the project directly.
- Agent state (sessions, memory, snapshots, skill caches) lives outside the project tree (e.g. `~/.local/share/opencode/`, `~/.claude/`), so nothing needs name-prefix classification.
- Access boundaries are enforced by permission rules (`external_directory`, `allow/ask/deny`), not by a second filesystem layer.
- Shell and file tools share the same root, so there is no view divergence.

This model achieves everything `projectWritable` is trying to achieve without dual-root routing, prefix classification, or overlay merge semantics.

## Questions for maintainers

1. Do you consider the current design a deliberate trade-off, and are the inconsistencies above known/accepted?
2. Is there a plan to move toward a single-root model (project as the root, agent state moved out of the filesystem namespace, boundaries enforced by permissions) — e.g. as a new filesystem spec or a breaking change for the next major version?
3. Would the maintainers prefer focused fixes on the current design (e.g. making non-metadata reads project-first under `projectWritable`) or a structural redesign?

Happy to turn any direction into a concrete implementation plan if there is appetite.