export enum declarations never produce an Export record, in either engine

[carlos-alm]

Summary

Discovered while investigating #2459. export enum Foo { ... } is correctly parsed as a real export_statement wrapping an enum_declaration in both engines, but the export-collection logic that turns a wrapped declaration into an Export record has no case for enum_declaration at all — it silently falls through to a no-op. The enum's Definition is still created (via the normal enum_declaration handler), just never marked exported=1.

Evidence

TypeScript (src/extractors/javascript.ts):

• EXPORT_DECL_KIND (line ~206) lists function_declaration, generator_function_declaration, class_declaration, abstract_class_declaration, interface_declaration, type_alias_declaration — no enum_declaration.
• collectExportedDeclarations (line ~240) checks EXPORT_DECL_KIND, then falls back to a lexical_declaration/variable_declaration-only branch. An enum_declaration passed in matches neither, so the function returns without pushing an Export.
• Meanwhile enum_declaration IS handled for definition-extraction purposes via handleEnumDecl (dispatched from walkJavaScriptNode's switch, line ~1516) — so the enum itself is extracted as a normal (internal) definition, just never flagged as exported.

Rust (crates/codegraph-core/src/extractors/javascript.rs):

• handle_export_declaration (line ~3158) matches decl.kind() against "function_declaration", "class_declaration"/"abstract_class_declaration", "interface_declaration", "type_alias_declaration", "lexical_declaration"/"variable_declaration" — no "enum_declaration" arm, falls to _ => return.
• enum_declaration IS separately dispatched for definitions via handle_enum_decl (line ~1875), same asymmetry as the TS side.

Both engines agree with each other (consistent, not a parity gap) — but both are wrong relative to real JS/TS semantics: export enum Foo {} genuinely exports Foo.

Repro

export enum Color { Red, Green, Blue }

Extracts Color as an internal enum definition; no matching Export entry is created, so codegraph exports <file> won't list it and nothing that queries "is this symbol exported" will see it as one.

Scope note

Filed separately per CLAUDE.md's scope-discipline rule — found as a side effect of investigating #2459 (bare export + newline misparse), which is an unrelated root cause (a tree-sitter grammar limitation, not a missing case in codegraph's own export-collection switch/match).