Re-reviewed against the actual diff (my earlier comment was based on bad local tooling output — disregarded).

This PR adds two server-side compatibility endpoints the browser dashboard already calls: GET /api/files/search (delegates to walk(cwd, prefix)) and GET /api/file-read preview (delegates to handleFileRead). Verified:

• walk() is scoped to cwd, RESULT_CAP=50, MAX_DEPTH=4, sensible SKIP_DIRS/SKIP_EXTS; q is only used as a lowercased substring filter on the relative path — never joined into a path, so no traversal vector.
• The preview reuses handleFileRead, which keeps its path-traversal guard (resolve + startsWith(cwd+sep) → 403) and FD-based read (fstat/read on the open fd, no TOCTOU).
• Test covers both the search match and the preview head/totalLines shape. CI green (build + CodeQL).

One non-blocking nit: handleFileReadPreview reads query.get("path") (already percent-decoded by URLSearchParams) and passes it to handleFileRead, which calls decodeURIComponent(rest.join("/")) again — a double-decode. Traversal is still blocked by the guard, so it's not a security issue, but a filename containing a literal % would resolve to the wrong path. Consider skipping the second decode for this call path. Not blocking the merge.

LGTM.