fix(server): contain static file requests within their served roots

[DeryFerd]

What

The embedded Studio server and the engine's render file server both took the raw request path, joined it onto their root directory, and opened whatever landed there. Nothing checked that the result stayed inside the root, so a request carrying percent-encoded separators or dot segments could name a file anywhere on the disk and receive its bytes. This change resolves the request path first and answers 404 for anything that collapses outside the root being served. Two handlers changed and two route-level test suites were added; no public API or serving behavior for legitimate assets is affected.

Why

Hono decodes percent escapes while it routes, and that decode is where the gap opens. On Windows an encoded backslash (%5c) arrives at the handler as a real path separator, so /assets/..%5c..%5csecrets.txt walks out of the Studio bundle directory, and the same shape works against the engine file server's projectDir and compiledDir. Browsers normalize dot segments before sending and never emit %5c, so ordinary Studio usage and capture sessions never produce these requests. The reachable senders are everything else that can touch the bound port: any local process, another user's process on a shared machine reaching the render server, and LAN peers whenever the preview server is bound to 0.0.0.0, which is a documented supported mode. Each of them can read files with the CLI user's permissions.

A realpath-based containment like the repo's resolveWithinProject would be the wrong tool here. Bundle and project assets are allowed to sit behind symlinked directories, and #3725 and #3728 deliberately preserved that behavior while hardening these same servers. What separates an attack from that supported workflow is lexical: dot segments collapsing upward through ... So the guard rejects escape-by-collapse and keeps serving symlinked assets exactly as before, which keeps the fix consistent with the tradeoff the preview asset route already documents.

How

Both handlers resolve the request path against their root and refuse the request when the resolved path lands outside it:

• packages/cli/src/server/studioServer.ts — serveStudioStaticFile, which backs the /assets/*, /icons/* and /favicon.svg SPA routes, now checks the resolved path before opening it.
• packages/engine/src/services/fileServer.ts — the GET /* handler checks both roots it serves, compiledDir when present and projectDir.

The check is isWithinProjectRoot from @hyperframes/parsers/asset-resolution, the same helper the preview asset route uses. It compares lexically, so an in-root symlinked or junctioned asset directory still resolves and still serves, while ../ collapse is rejected. Failures return the same 404 the handlers already used for missing files, so error responses do not leak whether a path escaped or simply did not exist.

The tests pin the behavior from the attacker's side. fileServer.pathSafety.test.ts starts a real listening server and fetches over HTTP, since that is the only faithful way to reproduce raw request shapes; it covers /..%2f, /%2e%2e%2f, a nested %2f hop, %5c, and repeated %5c variants, asserting that an outside file's contents never come back. On the previous handlers those requests return 200 with the file's bytes. studioServer.pathSafety.test.ts does the equivalent through the Studio app router with a marker file one level above the bundle root. Both suites also keep the positive cases green: in-root assets serve normally, the SPA shell still renders, cache headers are unchanged, and the symlinked-asset cases from the descriptor-pinning regressions still pass.

Test plan

• Unit tests added/updated — two new pathSafety suites; packages/cli/src/server passes in full (142 tests) and packages/engine/src/services matches the main baseline, including the pre-existing browserManager failures unrelated to this change
• Manual testing performed — the engine containment suite runs against a real listening HTTP server on an ephemeral port; typecheck, oxlint, oxfmt --check and the workspace build all pass
• Documentation updated (if applicable) — no user-facing behavior changes beyond the fix itself