refactor(files): split 945-line routes/files.py into a submodule

[AbstractNucleus]

What: routes/files.py is 945 lines (~19% of src/) and covers tree, view, save, upload, delete, mkdir, rename, move, download, search, bulk_delete, bulk_move — plus an in-process search-index cache.

Why: Cognitive load when touching any one concern. The matching test file is 2k+ lines.

Approach: Convert routes/files.py into a package: routes/files/{tree,view,write,mutate,search,_safety}.py. Lift the search index into mcontrol/file_search.py. Re-export the router from routes/files/__init__.py so existing imports stay green.

[AbstractNucleus]

This was generated by AI during triage.

Routed to ready-for-human — the cut lines for splitting routes/files.py carry real judgment:

• Where does the search index live vs the route that consumes it.
• Whether the path-safety helpers (refactor(files): lift path-safety helpers into mcontrol/file_safety.py #102) move first.
• Whether the 2k-line test file splits in the same PR or follows.

Worth a human pass on the target structure first; an agent can then do the mechanical move.

[AbstractNucleus]

Triage note: this and #100 are the two big layout refactors in the queue, and #97 introduces a services/ layer that would also reshape routes/files.py. All three should land after the in-flight feature work (#119, #123, remaining a11y surfaces of #110) to avoid every other branch carrying a rebase through a 945-line file move.

Order I'd suggest if/when they go: #97 (services boundary) → #101 (split files.py against the services seam) → #100 (top-level routes/domain/infra). But that's a sequencing question worth pinning explicitly before any of them start.

Holding for now.