feat: add Pascal / Delphi language support

[Cameron64]

Summary

Adds Pascal / Delphi (.pas, .pp, .dpr, .dpk, .inc) as a first-class language for Understand-Anything, backed by tree-sitter-pascal (Isopod/tree-sitter-pascal). Also makes two small additive extensions to StructuralAnalysis that benefit every language — particularly inheritance recovery, which is currently missing from the deterministic structural output across all extractors.

End-to-end validated against a 324-file legacy Delphi 7 codebase (19 MB / 461,452 lines): zero parse errors across the suite, and the resulting graph hits 6,113 nodes / 8,770 edges including 454 inherits edges, 7 implements edges, 1,944 imports edges (756 tagged interface-section vs 124 implementation-section), and 307 related edges (DFM filename pairings).

What's in the PR

New language module

• packages/core/src/languages/configs/pascal.ts — language config
• packages/core/src/languages/configs/index.ts — register
• packages/core/src/plugins/extractors/pascal-extractor.ts — AST walker for unit / program / library: extracts moduleName, declUses (interface- and implementation-section), declTypes → declClass / declIntf with ancestors, declProc / defProc with declArgs / typeref, declField, qualified-method names via genericDot, and a call graph via exprCall
• packages/core/src/plugins/extractors/index.ts — register PascalExtractor
• skills/understand/languages/pascal.md — LLM prompt snippet (concepts, import patterns, file patterns, common frameworks, example languageNotes)

Shared-type extensions (additive, all optional — no breaking changes)

In packages/core/src/types.ts:

StructuralAnalysis.classes[].parents?: string[]      // ancestor class names
StructuralAnalysis.classes[].interfaces?: string[]   // implemented interface names
StructuralAnalysis.imports[].section?: "interface" | "implementation"

These let every language extractor surface inheritance deterministically. Today, no extractor emits this on StructuralAnalysis so the file-analyzer agent has to re-read source to recover parents — which is inconsistent across batches. On the validation codebase, switching to deterministic inheritance jumped inherits edges from 140 → 454 (3.2×) and let the architecture-analyzer correctly classify reporting forms (38 → 201) instead of dumping them into a generic "Standalone" bucket.

skills/understand/extract-structure.mjs is updated to surface the new fields in its JSON output.

The other extractors are untouched and continue to work — the new fields are optional. Populating them for TypeScript / Python / Java / C# / etc. is a natural follow-up.

New post-merge helper scripts

• skills/understand/resolve-external-class-refs.mjs — generic, useful for any language. When file-analyzer agents emit inheritance edges pointing at class:external:<Name> because they don't know which file declares the parent (it's in another batch), this pass rewrites the edge target to the actual node ID by class-name lookup, then re-adds the edge to the assembled graph. On the validation codebase this recovers 194 cross-batch inherits / implements edges the merge step would otherwise drop as dangling.
• skills/understand/emit-dfm-pairs.mjs — Pascal-specific. Pascal forms come in paired .pas + .dfm files; this emits a related edge between each pair after merge.

Test plan

• Tree-sitter-pascal grammar (Isopod v0.10.2 built to wasm via tree-sitter build --wasm) parses real Delphi 7 source with zero error nodes across 324 sampled files
• extract-structure.mjs runs cleanly end-to-end on 25-file batches; new parents / interfaces / section fields populate as expected
• Full /understand pipeline produces a validated graph (0 issues, 0 warnings in inline validation) with all file-level nodes assigned to layers and all tour-step nodeIds resolving
• Unit tests for PascalExtractor — not in this PR, happy to add in a follow-up commit if you'd like them before merge

Open question for the maintainer

Distribution of tree-sitter-pascal.wasm. There's no published npm package shipping a prebuilt wasm for Pascal — the existing tree-sitter-pascal@0.0.1 on npm ships only C source via nan native bindings. Options to discuss:

• (a) Vendor the wasm into a small in-repo workspace package (packages/tree-sitter-pascal-wasm/ or similar). ~700 KB binary asset. Cleanest install experience.
• (b) Add an optional dependency with a postinstall build step that runs tree-sitter build --wasm against the grammar source.
• (c) Document a manual build step in the README — users install tree-sitter-cli, clone Isopod's grammar, build to wasm, and place it where require.resolve("tree-sitter-pascal/tree-sitter-pascal.wasm") finds it.

This PR intentionally leaves tree-sitter-pascal out of packages/core/package.json so existing CI / installs are unaffected. The TreeSitterPlugin's existing graceful-degradation path (catch + skip when the wasm doesn't resolve) means Pascal support is simply unavailable until a wasm is provided locally — same posture as if a user had no grammar at all. Once we agree on (a) / (b) / (c) I'm happy to add the dependency wiring in this PR or a follow-up.

🤖 Generated with Claude Code

[Cameron64]

Pre-empting two likely review asks — pushed two follow-up commits (9b7e663, 636b1da):

1. PascalExtractor unit tests — 13 tests covering import section-tagging, class inheritance (single parent / parent + multi-interface / pure interface inheritance / ancestor-less), procedure/function extraction (params, return type, qualified Class.Method names), and call graph. Skips cleanly via top-level await when tree-sitter-pascal.wasm isn't installed (the open distribution question), so contributors without the grammar can still run the rest of the suite.

2. parents / interfaces populated for every built-in extractor — to demonstrate the shared-type shape works for the full language matrix, not just Pascal:

• TypeScript (class_heritage → extends_clause / implements_clause): class Cat extends Animal implements Feline, Pettable → parents=["Animal"], interfaces=["Feline","Pettable"]
• Python (superclasses field): class Dog(Animal, Trainable): → parents=["Animal","Trainable"] (Python has no syntactic class/interface distinction, so all bases go in parents; metaclass= keyword args skipped)
• Java (superclass field + interfaces field; interface_declaration uses extends_interfaces): full split between parents and interfaces, plus interface-extends-interface → parents
• C# (base_list child node): applies the standard C# I-prefix convention via splitCSharpBaseRefs — if the first entry's bare name starts with I[A-Z] everything goes to interfaces; otherwise the first is the class parent and the rest are interfaces. Matches IDE outline behavior.
• C++ (base_class_clause child): class Cat : public Animal, protected Pettable → parents=["Animal","Pettable"] (C++ has no syntactic interface distinction)
• Go: no class inheritance, but embedded fields in structs (type T struct { Inner; *Other }) promote the embedded type's methods. Surfaced in parents since that's the closest Go semantic.
• Ruby: class Cat < Animal (superclass field) → parents; include Mod / prepend Mod / extend Mod mixins at class body top level → interfaces (they contribute methods at runtime, semantically like interface implementation)
• PHP (base_clause for extends, class_interface_clause for implements): clean split. Interface-extends-interface → parents.
• Rust: built a traitsByType map during impl_item walking — impl Trait for Type → interfaces on the matching struct/enum. trait Foo: Bar + Baz supertrait bounds → parents on the trait.

3. Fixed a real bug in PascalExtractor.extractCallGraph — Pascal allows bare-identifier procedure calls (Foo; instead of Foo();), which tree-sitter parses as (statement (identifier)) rather than exprCall. The extractor now records both shapes, filtered to skip non-call statements (assignments, binary expressions, statements with nested calls). Test coverage in the new suite.

All 241 existing extractor tests still pass; new Pascal suite is 13/13 when the grammar is available; smoke-tested every extractor against representative source for each language.