fix(core): LocationMutation resolves external paths against the server fs for workspace Locations

What

`LocationMutation.resolve` (`packages/core/src/location-mutation.ts:62-100`) is mostly lexical, but for external paths with unspecified kind it probes with process-local `fs.stat` (`location-mutation.ts:81`) and computes the permission save boundary via a process-local `Project.root` upward walk (`location-mutation.ts:93`). On a workspace-backed Location, external-path kind detection and `external_directory` permission boundaries therefore reflect the server host filesystem, not the sandbox the tools actually execute in.

Fix direction

Route the kind probe and the save-boundary walk through `Environment.files` for workspace Locations. This is safe for laziness: `resolve` runs during tool execution, which is already execution-plane and already provisions. Note `Environment.files` on workspace Locations is the spawner-derived coreutils implementation (`environment/exec-defaults.ts`), so each probe is one sandbox process — acceptable at tool frequency.

Acceptance

• External-path kind and save boundaries on a workspace Location reflect the sandbox filesystem (coverable with the memory driver's file overrides in tests).
• Local placement behavior and permission prompts unchanged.

Found while auditing boot-cycle process-vs-workspace resolution after #44526. Mechanical fix; no design dependency.

Start in packages/core/src/location-mutation.ts:62-100, then read environment/exec-defaults.ts to understand Environment.files for workspace Locations. Exercise LocationMutation.resolve with the memory driver's file overrides in tests. Done means external-path kind detection and save boundaries use the sandbox filesystem while local placement and permission prompts remain unchanged.