gdscript-db — the input layer for the analyzer.
Holds the virtual file system (FileId → text, always injected — never std::fs), the
project model, and (from Phase 3) the salsa query graph: #[salsa::input]s set via
apply_change, #[salsa::tracked] derived queries, durability tiers. The Phase-0/1/2
plain VFS map + reparse-on-change is being replaced here, localized behind the unchanged
gdscript-ide public API (Playbook §3.M0).
Crate boundary: gdscript-db is the base of the salsa stack — it owns the [Db] trait,
the inputs, and the [parse] query (it may depend on gdscript-syntax, never on
gdscript-hir). The higher queries (item_tree, analyze_file) live in gdscript-hir,
which depends on this crate for &dyn Db. This one-way layering is what avoids a
db ↔ hir dependency cycle.
FileId is deliberately not a salsa input. The FileId → FileText mapping is a side
table ([Files]) the database owns, mirroring rust-analyzer's base-db: FileIds are
assigned by the client/loader and stay opaque ids, while the salsa input is the text.
Must build for wasm32 (single-threaded; salsa with default-features = false).