fix(core): FileSystem read/list operations probe the server fs for workspace Locations

What

The Location `FileSystem` service body is entirely `FSUtil`-based: `resolve` calls a host `fs.realPath(absolute)` per operation (`packages/core/src/filesystem.ts:71`), and `read`/`list` stat and read through host `FSUtil` (`filesystem.ts:77-104`). For a workspace-backed Location, operations die when the path is missing on the host — or, worse, silently succeed against a same-named host directory and serve the wrong machine's files.

Fix direction

Route `resolve`'s per-operation canonicalization and the `read`/`list` bodies through `Environment.files` for workspace placements. This is execution-plane (operations already imply user intent), so provisioning on use is acceptable — but it shares the per-probe sandbox-spawn cost question with the boundary-walk in #44555's fix, and should follow the same seam design as #44552/#44553. Boot-time behavior is already correct after #44561 (PR #44564).

Acceptance

• `FileSystem.read`/`list` on a workspace Location reflect the sandbox filesystem (memory-driver coverable).
• A same-named directory on the server host is never read for a workspace Location.
• Local placement behavior unchanged.

Found while reviewing PR #44564; sixth surface in the boot-cycle process-vs-workspace audit alongside #44552, #44553, #44554, #44555, #44561.

Start in packages/core/src/filesystem.ts at resolve and the read/list bodies, then compare the workspace seam design in #44552 and #44553. Trace Environment.files and use the memory driver to verify workspace reads and listings reflect the sandbox, never a same-named host directory, while local placement remains unchanged.