…rted

Remove the 'intraprocedural only' limitation bullet. Replace with accurate
caveat about incremental re-stitch on the native engine path (#1614).
Update feature descriptions at lines 110 and 203 to mention the new
interprocedural edge kinds (arg_in, return_out, def_use).

…irectory nodes

extractDataflowAnalysis returns DataflowArgFlow with flat bindingType string
rather than the binding:{type,index} object that buildDataflowVerticesAndEdges
expects. Without normalisation, accessing af.binding.type crashes with
'Cannot read properties of undefined (reading type)' and causes the native
orchestrator to fall back to the JS pipeline on every incremental build,
leaving arg_in inter-procedural edges missing.

Fix: export patchDataflowResult from parser.ts and call it on each
DataflowResult from extractDataflowAnalysis in runDataflowVertexPass.

Also fixes the EISDIR error on full builds where the node query included
directory-kind nodes — filter those out so readFileSafe only reads files.

buildDataflowVerticesFromMap only collected stitch candidates from changed
files, leaving arg_in edges to recreated param vertices unconnected for
unchanged caller files. This caused incremental native builds to produce fewer
inter-procedural dataflow edges than full builds.

Fix: export collectCallerStitchCandidates and collectFuncIdsForFiles from
dataflow.ts so runDataflowVertexPass can invoke P4 re-stitch for unchanged
callers of changed functions, matching the behaviour already present in the
JS buildDataflowEdges path (issue #1614).

README.md:940 still said the incremental re-stitch pass only fires on the JS
engine path, but this PR adds it to the native vertex pass. Update the note
to reflect that P4 re-stitch now runs on both paths and closes issue #1614.

Also remove nativeDb from the wasmStubs buildDataflowEdges call: wasmStubs
have no .dataflow property so the native bulk-insert fast path is always
skipped for them, making nativeDb unused and its presence misleading.

… fk constraint

When migration 18 adds dataflow.call_edge_id REFERENCES edges(id), deleting
edges while dataflow rows still reference them via call_edge_id triggers
SQLITE_CONSTRAINT_FOREIGNKEY. This affects three code paths:

- JS incremental.ts: deleteOutgoingEdges for reverse-dep files
- Rust detect_changes.rs: purge_changed_files and reverse-dep edge deletion
- Rust pipeline.rs: reparse_barrel_candidates barrel edge deletion (which
  had PRAGMA foreign_keys ON from a prior full build on the same connection)
- Rust connection.rs: purgeFilesWithReverseDeps napi method

Also align Rust purge_sql ordering with JS purgeFileData: delete
dataflow_vertices and dataflow_summary before nodes to satisfy their fk.

…builds

On full builds the P6 vertex extraction pass previously called
extractDataflowAnalysis() for every file in the project, doubling the
effective analysis cost (Rust parses all files once, then JS re-parses
them all again). The regression measured +54-134% on the full build
benchmark against the 3.13.0 baseline.

Fix: scope filesToProcess to files that actually have dataflow edges
already written by the Rust orchestrator (flows_to/returns/mutates).
Native-language files with no dataflow edges produce zero vertices and
zero inter-procedural edges, so skipping them is safe. Non-native files
are always included so the WASM fallback path (buildDataflowEdges) can
write both edges and vertices for those languages.

Also adds KNOWN_REGRESSIONS entries for the remaining regression on the
3.13.0 baseline (the residual cost of processing files that DO have
dataflow edges, which is genuine new work) and for the fnDeps depth 1
query metric (CI runner variance on a sub-50ms native metric — the
fnDeps query path reads nodes/edges only and is unaffected by the
dataflow table additions).

…esult directly