security: require the local-control principal on GET /files

What

GET /files now carries the same require_local_control_principal dependency that GET /files/changes gained in #1842. A test mirrors the existing /files/changes capability test: the listing returns 401 without the renderer capability header and 200 with it.

Why

The email and project_id query parameters select a user's project root; nothing on this route authenticated the caller. Any process that can reach the Brain port could list any user's project files by naming them. With the default bind now on loopback the reach is local processes; deployments that set EIGENT_BRAIN_HOST=0.0.0.0 (Docker, Web mode) expose it to the network.

The frontend already sends the capability header for this call (useProjectOutputFiles.ts goes through fetchGet, which attaches X-Eigent-Local-Capability), so no renderer change is needed.

Not covered here, deliberately

GET /files/stream and GET /files/preview/... have the same shape but are loaded as <iframe> / <img> sources (Folder/index.tsx), which cannot carry a request header. Protecting them needs either a short-lived signed token in the URL or session.webRequest.onBeforeSendHeaders in the Electron main process scoped to the Brain origin. Happy to follow up with either if maintainers have a preference.

Verification

python -m py_compile on both files. The full backend suite needs Python 3.11 and the camel-ai tree, which the machine that prepared this does not have, so CI is the first full run.

Found by commitwork.