Restore content-based file typing with Magika v2 (pure Rust) once it is production-ready

[ebursztein]

Context

capsem-service used the magika crate (ONNX Runtime via ort) to classify files for the file-browser routes (GET /vms/{id}/files/list and /files/content). It is being removed as part of the #228 surface reduction:

• it ran an ML model over guest-controlled bytes inside the privileged host service, on every listed file (depth up to 6), under one global mutex, so a guest could make listings expensive just by creating files;
• it pulled 13 crates reachable only through it, including ONNX Runtime fetched from a third-party CDN at build time (macOS) and a separate ORT install step in the Linux build image;
• the service .expect()ed ORT initialisation, so a runtime problem there was a startup panic.

The replacement keeps the same response fields (label, mime, is_text) using a small extension table plus a bounded UTF-8/NUL sniff of the file head, and downloads are served as application/octet-stream. The UI only uses these fields for image/SVG preview, binary-vs-text, and syntax-highlighting language (which is extension-based already).

Ask

Magika has moved to a pure-Rust implementation (v2) that is not production-ready yet. When it is:

• evaluate it as a no-C, no-download dependency (supply chain, binary size, startup cost);
• decide where it runs — prefer a bounded, sandboxed context (e.g. the browser/webview on demand for a file whose type is unknown) over the privileged host service;
• if it returns to the service: bounded head bytes, off the async workers, no global lock, and no panic on init failure;
• keep the extension/UTF-8 fallback as the default path and cover the switch with the existing fs_utils and Ironbank file-ledger tests.

The code carries a TODO(magika-v2) pointing here.