Supertag CLI v2.6.0

Fixed

• gquery ... CONNECTED TO returned no rows when the reference sat on a child node, and lost matches past the first page (#99, #100) — getRelatedNodes read child/parent edges from the references table, which the indexer never writes, and the executor capped the FIND set at LIMIT and each traversal at 100 before filtering by tag. New src/db/graph-edges.ts derives edges set-based with no limit: tree edges from nodes.parent_id, field edges from field_values (with the field name), and inline refs from a node's untagged descendants up to depth 3. Traversal filters by target tag over the whole hop, FIND pages through the tag until LIMIT connected rows exist, and VIA <field> matches the field name case-insensitively. tana_related gets child/parent edges from nodes.parent_id (field tuples excluded) and field edges carry relationship.field. New index on field_values(value_node_id).
• tana_semantic_search (MCP) and supertag search --semantic (CLI) returned different results for the same query (#98) — the cause was not LanceDB nprobes (both call the same TanaEmbeddingService.search with no probe setting) but two diverging filter pipelines: only the MCP dropped trashed nodes, the MCP dedup key omitted tags in raw mode so same-named nodes merged, the MCP dropped matches whose contents failed to load, and the threshold and dedup ran in a different order. Both surfaces now call one shared runSemanticSearchPipeline (over-fetch, drop trashed and [[...]] nodes, tag filter, dedup by name+tags, threshold, limit) and keep only presentation. The CLI now also hides trashed nodes. Default limits stay 10 (CLI) and 20 (MCP); with the same --limit/limit both return the same nodes in the same order. Dedup no longer reorders a result's tag array in place.
• Supertags with duplicate names collapsed in the supertags registry (#123, refs #109) — TanaExportParser.buildGraph keyed its supertag map by name, so a later tagDef with the same name replaced the earlier one: supertags (and the field-name mapping) could list only an empty duplicate while tag_applications kept the instances under the real tag ID. The map is now keyed by tag ID and every tagDef is registered. Every name resolver (tags show/fields/inheritance, tag add/remove, create, field resolution, tana_supertag_info, table, tags visualize, search --tag --include-descendants) now picks among same-named tags with one rule: most inheritance parents, then most own fields, then most applications, then lowest tag ID. tana_supertag_info and table now also resolve tags that have no own fields. Run a full supertag sync index to rebuild the registry.