feat: ArkTS (.ets) and HarmonyOS project config support

[davien]

Adds full first-class support for HarmonyOS development.

ArkTS language (.ets)

ArkTS is HarmonyOS's UI language — a strict superset of TypeScript. The only non-TS syntactic feature is the struct keyword for UI components; decorators are already valid TS (experimentalDecorators). We preprocess struct → class (same byte length, line numbers preserved) and then enrich the extraction with HarmonyOS-specific semantics.

Decorators with real semantics (not just names)

• Component-level (→ decorates edges, struct upgraded to arkts_component):
  @Component, @ComponentV2, @Entry, @Preview, @CustomDialog, @Reusable, @ReusableV2
• Observation (→ observes edges):
  @Observed, @ObservedV2 + @Trace field binding
• State (→ contains_state edges, distinct arkts_state node type per field):
  @State, @Prop, @Link, @Local, @Param, @Provide/@Consume, @Provider/@Consumer, @StorageLink, @StorageProp, @LocalStorageLink, @LocalStorageProp, @Computed, @Event, @Once, @Watch, @Monitor, @Require, @BuilderParam, @ObjectLink
• Builder (recognized, grouped): @Builder, @Styles, @Extend, @AnimatableExtend, @Concurrent

Semantic edges beyond decorator names

• @watch('method') → watches edge to the target method in the same struct
• @monitor('field1', 'field2') → one monitors edge per target expression
• @Provide/@consume cross-component flow → synthetic arkts_provide_key nodes that producers and consumers join on — lets you query "who provides key X and who consumes it"
• @StorageLink/@StorageProp → arkts_app_storage_key node + storage_binds edge
• @LocalStorageLink/@LocalStorageProp → arkts_local_storage_key node + local_storage_binds edge
• build() body → uses_component edges from parent struct to every capitalized-identifier-called-as-function inside the build tree (Column(), NavDestination(), ForEach(), user components, etc.)
• $r("app.xxx.yyy") / $rawfile("…") → arkts_resource nodes + references_resource edges, shared by key across components
• Lifecycle methods (aboutToAppear, aboutToDisappear, onPageShow, onPageHide, onBackPress, onCreate, onWindowStageCreate, etc.) → tagged arkts_lifecycle + has_lifecycle edge
• Multi-line decorator args (@Entry({ routeName: ... })) handled via paren-depth tracking

Helpers

• _find_struct_ranges: brace-balanced struct/class scanner with string-literal awareness (handles '...', "...", `...` without miscounting)
• _containing_struct: line → struct lookup so all enrichment edges attach to the right parent

HarmonyOS project config files

Adds structured extraction of project-level config that previously was silently skipped:

File	Emits
module.json5	harmony_module + harmony_ability + harmony_extension_ability + harmony_permission, with declares_ability, declares_extension_ability, requires_permission edges
router_map.json	harmony_route per entry + INFERRED route_maps_to edge to the page component (ID inferred from pageSourceFile stem + route name)
oh-package.json5	harmony_package + harmony_dependency, with depends_on / dev_depends_on / dynamic_depends_on distinguishing the three dep kinds
build-profile.json5	harmony_build_profile + configures_module edges

• Minimal _parse_json5() helper — strips // comments, /* */ block comments, and trailing commas, then hands to json.loads. No new dependency.
• Filename-based dispatch in extract() (same pattern already used for .blade.php).
• detect.py routes these files to FileType.CODE so they enter the normal extraction pipeline.

Tests

29 new tests covering ArkTS language (10), V1+V2 semantic enrichment (12), and HarmonyOS config files (7). 462 total passing, zero regressions.

Verified on a real HarmonyOS RTC SDK (ZKJAIRTCDemo):

• EnvCheckPage.ets → 60 nodes / 87 edges (27 resources, 10 UI components, 5 observes edges, 2 @ObservedV2 classes)
• router_map.json → 6 routes + 6 route_maps_to edges
• oh-package.json5 → 5 HAR dependencies extracted

Migration / compatibility

• _extract_generic gains an optional source_override parameter so extract_ets can inject preprocessed bytes while keeping metadata tied to the real file. All other callers unaffected.
• No new required dependencies. JSON5 parsing is self-contained.
• All new node/edge types are additive — existing graphs unchanged for non-.ets projects.

Happy to split into smaller PRs or adjust the API (e.g. factoring _enrich_arkts into a separate module) if preferred.