Function build_ecosystem 

pub fn build_ecosystem() -> Ecosystem

The highlight registry escriba renders through: tree-sitter grammars (hikari-ts) take precedence for the languages they cover, and the zero-dep table backend fills every other language. So .rs gets real tree-sitter highlighting while .py / .lisp / .json / … get the batteries-included table lexer — and both flow through the same coverage-complete HlClass partition. Registration order is load-bearing: Ecosystem::resolve returns the first matching plugin, so tree-sitter (registered first) wins for its languages; the table backend is skipped for any language tree-sitter already covers (no duplicate). If the tree-sitter host fails to build, the table backend covers everything — never a panic, never an empty registry.

A third tier registers last: crate::langs::escriba_local, the languages escriba serves that the fleet spine does not ship yet (today: blue). Last means an upstream hikari backend for the same language always wins, so a local table retires itself the day hikari grows one — no edit here, and no window where the two disagree.

Public because the registry IS escriba’s language surface: a test that asks “does the editor know this language?” must be able to ask the same object the renderer holds, not a reconstruction of it.