Spike: Pierre's @pierre/diffs and @pierre/trees in flue #129

Why

Pierre (pierre.computer) open sourced the rendering layer of their code review product: @pierre/diffs and @pierre/trees, Apache-2.0, in the pierrecomputer/pierre monorepo, with diffshub.com as an open reference app (apps/diffshub) that wires the two together. The diff renderer is the most seriously engineered one on npm right now (per-line virtualization, worker pool highlighting, a 36 million line diff in their demo; see "On Rendering Diffs"). Before the code browser (#127) and the diff view (#130) pick components, find out whether these fit flue's constraints. Answer is a recommendation, the branch is throwaway.

Questions, each answerable yes or no

1. CSP. The daemon and the relay serve the UI under script-src 'self' with no wasm-unsafe-eval, which is why file peek runs shiki on @shikijs/engine-javascript (web/src/files/tokenize.ts). @pierre/diffs depends on shiki ^3 || ^4 and its worker ships an oniguruma wasm shim. Can the highlighter or engine be injected so it runs wasm-free? If not, it is out, or the CSP loosens, and the file peek design already decided the feature bends around the CSP.
2. One shiki. flue already ships shiki v4 as lazy assets/peek/* chunks. Every independent adopter who hit trouble hit the same thing: grammars in the critical path or a second copy of shiki (get-bb#1070, 814 KB to 2.5 KB after lazy loading; devframe#264 migrated off over the duplicate). Can @pierre/diffs share flue's shiki instance and grammar chunks, and stay out of the entry bundle? Measure the net gzip delta; the package alone is about 170 KB gzip.
3. Theming. Both packages render into shadow DOM and take colours through @pierre/theming, which parses shiki or VS Code theme JSON. Can they be fed flue's tokens from web/src/styles.css and the min-light / min-dark pair the viewer uses, and end up looking like flue rather than like Pierre? Or does the shadow root wall off Tailwind to the point where it is a second design system?
4. Trees and lazy loading. @pierre/trees takes paths: string[], the complete list, and has no async loadChildren. It was demoed on 1.5 million files so scale is not the concern; enumeration is. Can lazy expansion be faked with tree.add() on expand, fed by the list verb in Fast directory listing over the wire for big repos #128? Or does trees only make sense once the path index in Fast directory listing over the wire for big repos #128 exists, with an own tree on @tanstack/react-virtual (already in the viewer) as the v1?
5. Stability. trees is 1.0.0-beta.6 with API changes between betas; the diffs worker API is labelled experimental. Acceptable for a dependency in the daemon's embedded UI, which ships on the daemon's release cadence, not the browser's?

Notes

• Fallback to name now: @headless-tree/core supports async data loaders and is what Pierre started on before inlining their own core (their NOTICE.md credits it).
• @pierre/storage is a client for their hosted git service, not a local git library. Nothing there for flue.
• Exit: a short write-up per package, go or no go, with the measured bundle numbers. No merge.