fix(opencode): avoid search retention for file reads

[hereswilson]

Issue for this PR

Closes #32237

This may also be related to #20695, but this PR only addresses repeated file route reads initializing and retaining search state.

Type of change

• Bug fix
• New feature
• Refactor / code improvement
• Documentation

What does this PR do?

Repeated /file/content reads were going through the cached location file system service. That service can initialize and retain file search state, even though reading one file does not need search.

This changes the file system service so search is loaded lazily. read and list no longer initialize search. find, glob, and grep still load search when they need it.

The HTTP file handlers now use a direct file system layer for /file/content and /file. /find/file still uses the cached location services because search benefits from being warm.

I also added tests for the important behavior:

• reading a file does not initialize search
• listing files does not initialize search
• repeated and concurrent searches initialize search once
• search resources stay alive until the file system layer closes
• search still returns results when used
• search paths cannot escape the location
• existing VCS and non VCS search limits are preserved
• file list still marks ignored files from the project root

How did you verify your code works?

I verified this with focused tests, type checks, and a local workload harness.

The harness is outside this repo. It creates temporary workspaces, starts opencode serve, calls file routes, and samples opencode-serve Resident Set Size during the run.

Focused /file/content workload:

• 12 workspaces
• 100 steps
• 80 files per workspace
• 128 KB per file
• Bun 1.3.14
• Windows 11 Home

Before this change:

• retained Resident Set Size growth: 523.1 MB
• peak Resident Set Size: 993.0 MB

After this change:

• retained Resident Set Size growth: 59.2 MB
• peak Resident Set Size: 522.8 MB
• harness findings: 0

Warm read latency did not regress in the same run. Warm /file/content reads were p50 34.2 ms, p95 55.5 ms, p99 66.4 ms.

I also checked adjacent file routes. /find/file still uses the cached search path, and warm search latency stayed in the same range.

Local checks:

• bun test test/location-filesystem.test.ts from packages/core
• bun test --timeout 30000 test/server/httpapi-file.test.ts test/server/httpapi-sdk.test.ts from packages/opencode
• bun typecheck from packages/core
• bun typecheck from packages/opencode
• Prettier check
• oxlint
• git diff --check

Screenshots / recordings

N/A. This is not a UI change.

Checklist

• I have tested my changes locally
• I have not included unrelated changes in this PR