### Problem to Solve The code indexer writes fine-grained `RelationshipType` strings into the `relationship_kind` column of `gl_edge` — values like `FILE_DEFINES`, `CLASS_TO_METHOD`, `IMPORTED_SYMBOL_TO_DEFINITION`, `DIR_CONTAINS_DIR`, etc. The query engine filters that column using ontology edge names from `fixtures/ontology/edges/`: `DEFINES`, `IMPORTS`, `CALLS`, `CONTAINS`. These never match the values the indexer writes, so any query traversing code graph edges returns nothing. Additionally, the `CONTAINS` ontology edge is missing `Directory → Directory` and `Directory → File` variants, so even with correct labels there's no ontology definition covering directory containment. ### Proposed Solution Add a mapping function in `arrow_converter.rs` that translates each `RelationshipType` variant to the correct ontology edge label before writing to ClickHouse: - `DirContainsDir`, `DirContainsFile` → `CONTAINS` - `FileDefines`, all definition-to-definition variants, `DefinesImportedSymbol` → `DEFINES` - `FileImports`, all `ImportedSymbolTo*` variants → `IMPORTS` - `Calls`, `AmbiguouslyCalls`, `PropertyReference` → `CALLS` Add the missing `Directory → Directory` and `Directory → File` variants to `fixtures/ontology/edges/contains.yaml`. Update the integration test to assert on the corrected labels. Keep the fix at the serialization boundary in `arrow_converter.rs` rather than refactoring the `RelationshipType` enum across `code-graph`. The fine-grained types are still useful internally — a deeper refactor (\~20 files across 7 language analyzers) can follow separately if needed.