fix(ts): a re-export imports its module, and sync follows barrels of barrels (#2526)

An `export … from './x'` statement emitted one `imports` reference per
re-exported name and nothing for the module itself; `export * from` emitted
nothing at all. So a barrel made only of `export *` lines had no dependency
on what it re-exports (no dependent for `affected`), and sync could not find
an `index.ts` that re-exports another barrel: when the inner one was deleted
or added, the outer one's importers kept their stale or name-matched edges.

A re-export now imports its module the way `import … from` does, in both
extractors (TS and the Rust kernel): an import node named by the specifier
and a module reference that links the barrel to the file it names. Sync's
importer discovery follows such modules to their own importers, carrying
the names each passes on (`export *`, a named or renamed re-export, an
`export * as ns`), as deep as the resolver chases a re-export; an ES
namespace import reads whatever its module passes on. A re-export's import
node does not count as a symbol for the "parse produced no symbols" warning,
so a barrel with an unparseable line still reports it.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

codegraph-kernel/src/tsjs/mod.rs

@@ -721,7 +721,10 @@ impl<'t> Walker<'t> {
         } else if kind == "import_statement" {
             self.extract_import(node);
         } else if kind == "export_statement" && node.child_by_field_name("source").is_some() {
-            // Re-export: `export { X } from './y'`.
+            // Re-export: `export { X } from './y'`, `export * from './y'`. It
+            // imports the module as `import … from` does (an import node and a
+            // reference to the module), then links each re-exported name.
+            self.extract_import(node);
             self.emit_re_export_refs(node);
         } else if kind == "export_statement" && self.looks_like_vue_store_file() {
             // Vuex MODULE default export (`export default { actions: {…} }`).