Re-check consumer scripts when an included module changes (#165)

[bentsherman]

Overview

Follow-up to b29edb8 for #165. That commit fixed the cold-scan false warning by type-checking included modules before their includers. This addresses the remaining incremental-invalidation half of the issue:

Editing a module does not re-check its consumers, so a stale false warning lingers in the editor until the consuming file is touched.

Root cause

Editing a module did add its direct consumer to the change set, so the consumer was re-type-checked — but only the directly-changed files are re-parsed. Consumers pulled in during analysis were re-type-checked over their old AST nodes, which still carried INFERRED_TYPE metadata from the previous run. Since getType() short-circuits on cached INFERRED_TYPE, a changed process output type was never observed (e.g. ch_produced kept resolving to the stale Channel<Record{id, data}>). Transitive consumers (A → B → C) were never re-checked at all.

Fix

Add an expandInvalidation() hook in ASTNodeCache.update() (default no-op) that runs before parsing. ScriptAstCache overrides it to walk the reverse include graph and pull every transitive consumer into the invalidation set, so consumers are re-parsed from fresh (metadata-free) AST nodes and their cross-file inferred types are recomputed. Reuses the existing parse→analyze pipeline and the localIncludeUri helper.

Testing

New test in ScriptDiagnosticsTest: with a compatible producer→consumer wiring, edit only the producer module to emit an incompatible record → the consumer call now reports the mismatch; restore the producer → the stale warning clears. Verified it fails without the fix and passes with it. Full suite green.

Known ceiling

expandInvalidation rebuilds the reverse graph each update and localIncludeUri does one Files.isDirectory stat per include — fine at debounced-update cadence; memoize if it shows up on a large workspace. Remote/plugin includes are still not tracked.