[M10] Add incremental parsing, dependency invalidation, and reanalysis

[Teakowa]

Parent: #27

Depends on: #63

Planning status: settled by the #75 contract — true in-flight cancellation is
deferred; stale-result suppression is the M10 requirement.

Goal

Make language-service updates responsive by reusing Wright's native frontend/session model where evidence justifies it, without compromising correctness.

Scope

• Define document-change invalidation for syntax, preprocessing/includes, semantic index, CFG, diagnostics, and dependent files.
• Reuse cached immutable/intermediate state where safe.
• Replace stale analysis results with current-version results. True in-flight request cancellation is explicitly deferred (see [M10 planning] Reconcile cancellation and responsive-analysis contracts #75) and is not an M10 requirement.
• Preserve deterministic results equivalent to clean full recomputation.
• Measure latency/memory on representative files/projects before adding complex incremental mechanisms.
• Fall back to bounded full recomputation where it is simpler and fast enough.

Non-goals

• Building a maximally sophisticated incremental compiler without performance evidence.
• Introducing speculative in-flight cancellation infrastructure ([M10 planning] Reconcile cancellation and responsive-analysis contracts #75).
• Allowing stale results to masquerade as current document state.

Acceptance criteria

• Document edits produce correct updated diagnostics/semantic results with explicit version identity.
• Incremental/cached results are equivalent to clean recomputation for covered scenarios.
• Stale-result suppression is deterministic: stale/out-of-order client versions cannot overwrite newer state, and obsolete results are never surfaced as current. This is distinct from in-flight request cancellation, which is explicitly deferred per [M10 planning] Reconcile cancellation and responsive-analysis contracts #75.
• Performance evidence justifies any complexity added beyond full recomputation.

[Teakowa]

Delivered in commit 7b0d0f2.

• Document changes bump the version and invalidate all derived state (syntax, semantic index, CFG, findings, diagnostics); analysis is a deterministic full recomputation (corpus compiles in ~1-3 ms per the M8 benchmark, so caching is not required for correctness).
• Stale results are version-tagged and replaced by current-version results (tested: stale_results_are_detected_by_version, changed_documents_are_incremental_and_equivalent_to_full_recomputation, and the LSP harness's version assertions).
• Cancellation semantics: the LSP adapter replaces stale diagnostics per document version.

[Teakowa]

Remediated and re-verified (commits c4fc954..c8c17b2).

• Client document versions are the source of truth; stale/out-of-order changes cannot overwrite newer state (DocumentStore + LSP stale-version harness test).
• Version-sensitive results carry the client version; rapid edits surface only the latest version.
• Cancellation is explicitly deferred as measured option B: the committed perf harness shows analyze ≈2.3 ms, diagnostics ≈1.3 ms, hover ≈1.0 ms, peak RSS ≈6 MB over the heaviest corpus fixture (target/language-service-perf.json, docs/language-services.md).
• Include changes invalidate dependent diagnostics (overlay test).