…ra def_use edges

docs check acknowledged

Implements the WASM/JS-path vertex extraction phase of the interprocedural
dataflow plan (§8 P1).

buildDataflowVerticesAndEdges (new, in features/dataflow.ts):
- Creates 'param' vertices from each function parameter (name + index)
- Creates one 'return' vertex per function that has a return statement
- Creates 'local' vertices for variables assigned from call-return results
- Emits 'def_use' / 'intra' edges from param/local → return when the
  variable name appears in the return expression's referencedNames set
- All new rows use the source_vertex/target_vertex/scope columns added
  in v18; source_id/target_id are set to the enclosing function for
  backward compatibility with existing queries

Internal cast types (VisitorParam, VisitorReturn, VisitorAssignment) allow
safe access to the richer visitor output (paramName, paramIndex,
referencedNames) without changing the public DataflowResult contract.

Existing flows_to/returns/mutates edges are unchanged. The native bulk-
insert fast path is left untouched — native vertex emission tracked
separately.

Tests: 9 new assertions in tests/integration/dataflow-vertices.test.ts —
param/return/local vertex creation, def_use edge creation, negative test
(param not in return expression → no edge), backward-compat flows_to edge,
dataflow_fn view empty pre-P2.

32/32 integration tests pass (23 existing + 9 new).

…mmaries

docs check acknowledged

Implements the interprocedural stitch post-pass and summary computation
for the variable-level dataflow model (plan §8 P2).

buildInterproceduralStitch (new):
- Post-pass that runs after all per-file vertices + summaries are committed
- For each resolved argFlow (A calls B with arg x → B.param[j]):
  - Finds source vertex x in caller (via binding.type='param'|'local')
  - Finds B.param[j] vertex in callee
  - Emits 'arg_in' scope='inter' edge: x → B.param[j]
  - If B's summary shows B.param[j] flows_to_return: emits 'return_out'
    edge: B.return → A's capture local (if any)
- Resolves call_edge_id from the edges table for each stitch site

buildDataflowVerticesAndEdges (updated):
- Now also computes dataflow_summary (flows_to_return, is_mutated per param)
  using the def_use edges just committed (same transaction)
- Collects and returns StitchCandidate[] + ReturnCapture[] for the post-pass

buildDataflowEdges (updated):
- Accumulates stitch candidates across all files
- Calls buildInterproceduralStitch as a second-pass transaction

Tests: 11 P1+P2 assertions passing:
- param/return/local vertex creation
- def_use intra edges (positive + negative cases)
- summary computation: helper.param[y] flows_to_return=1, param[x]=0
- arg_in inter edge verified in both dataflow_fn view and raw query
- scope='inter', correct vertex kinds (param→param)

34/34 integration tests pass (23 original + 11 new).

…r extension

docs check acknowledged

Adds DATAFLOW_RULES for the C-family batch (B1) of the 26 new languages.

Infrastructure (needed by C/C++ and future complex languages):
- DataflowRulesConfig.nameExtractor optional override: when present,
  used by functionName() in visitor-utils.ts before the nameField path —
  handles languages where the function name is nested inside declarators
- DataflowRulesConfig/DATAFLOW_DEFAULTS/LanguageRules updated consistently

src/ast-analysis/rules/c.ts (new):
- extractCFunctionName: unwraps C/C++ function_definition.declarator →
  function_declarator.declarator → identifier, handling pointer/array/
  reference/parenthesized/qualified_identifier wrappers
- extractCParamName: extracts identifier from parameter_declaration,
  unwrapping pointer/reference declarators
- dataflow (C): covers function_definition, call_expression,
  field_expression (member access), return_statement, init_declarator
- dataflowCpp (C++): extends C with function_declaration and STL
  mutating method names

DATAFLOW_RULES additions:
  'c' → c.dataflow
  'cpp' → c.dataflowCpp
  'objc' → c.dataflow  (C-compatible functions; ObjC message sends TODO)
  'cuda' → c.dataflowCpp  (CUDA inherits C++ grammar)

34/34 integration tests pass.

Three bugs in the new C/C++ dataflow extraction path (P5 B1):

1. extractCFunctionName dropped pointer/reference-returning functions
   (int *foo(), T &bar()): the direct declarator child is a
   pointer_declarator wrapper — now unwrapped one level before checking
   for function_declarator.

2. Parameter list was unreachable for all C/C++ functions: params live
   on function_definition→declarator→parameters (nested), not directly
   on function_definition. Added getParamListNode optional override to
   DataflowRulesConfig/DATAFLOW_DEFAULTS/enterFunctionScope; C rules use
   getCParamListNode which traverses through optional wrappers to reach
   function_declarator.parameters.

3. dataflowCpp.functionNodes included function_declaration (forward
   declarations without bodies): these produce spurious param vertices
   with flows_to_return=0 and can overwrite correct dataflow_summary rows
   via INSERT OR REPLACE when processed after the definition.

Adds 29 passing tests covering all three paths for C and C++.

…y-compare

Two issues in scripts/parity-compare.mjs:

- readDataflowVerticesMultiset swallowed all SQL exceptions, hiding
  schema drift, malformed queries, and corrupt-DB errors; now only
  suppresses "no such table" (pre-v18 DBs), re-throwing everything else.

- dfVertexDiffs was always [] in JSON output when --dataflow was not
  passed, while dfVertexCount was absent (undefined). JSON consumers
  couldn't distinguish "comparison attempted, no diffs" from "comparison
  not attempted". dfVertexDiffs is now undefined when --dataflow is off,
  matching the dfVertexCount convention; ok computation updated to match.

Also clarifies the dataflow_fn view comment in src/db/migrations.ts:
the view INNER JOINs are intentional (only vertex-linked v18+ rows), not
a backward-compat bridge — migrating code from direct dataflow queries to
dataflow_fn would silently drop pre-v18 rows.

…nner variance