fix(core): ripgrep binary resolution ignores workspace placement

What

Ripgrep spawning routes through the Location environment (`ripgrep.ts:103,118-119`), so on a workspace-backed Location the process runs inside the remote sandbox. But the binary path is resolved on the server host: `RipgrepBinary` (`packages/core/src/ripgrep/binary.ts:31-135`) uses local `which`, `FSUtil`, `global.bin`, and HTTP download. A remote sandbox gets handed a server-local absolute path such as `~/.local/share/opencode/bin/rg` and the spawn fails.

Fix direction

Executable identity must follow placement. For workspace Locations, use the provider's executable identity (bare `rg` on the image PATH, or a driver-declared capability); keep local resolution/download only for implicit-local placement. This is the deferred "Environment-owned ripgrep executable selection" item from #44526 — the seam decision (executable resolver vs capability metadata vs search override on `Environment.Driver`) needs to be made first.

Acceptance

• A fake workspace driver that rejects host-absolute binary paths passes filesystem search.
• Local placement behavior unchanged, including download fallback.

Found while auditing boot-cycle process-vs-workspace resolution after #44526.

Start with packages/core/src/ripgrep/binary.ts, especially lines 31-135, and the ripgrep.ts references at lines 103 and 118-119. Trace how Location and Environment.Driver determine executable placement, then use the fake workspace driver acceptance case to verify that remote execution avoids host-absolute paths while local resolution and download fallback remain unchanged.