PR: perf(language-service): progressive project initialization

Description

Replaces the blocking project.refreshDiagnostics() during project initialization with a progressive background approach. Instead of sending all diagnostic refresh events at once, open files are now processed in configurable chunks with event loop yields between them, keeping the IDE responsive during Angular project startup.

Problem

When a project finishes loading (ProjectLoadingFinishEvent), the language server calls:

this.runGlobalAnalysisForNewlyLoadedProject(project);
project.refreshDiagnostics(); // triggers diagnostics for ALL open files at once

The project.refreshDiagnostics() call sends a ProjectsUpdatedInBackgroundEvent which triggers diagnostic computation for all open files. While the existing sendPendingDiagnostics already yields between individual files, the initial event processing can still cause a burst of work that degrades IDE responsiveness during startup.

Solution

Replaced project.refreshDiagnostics() with a new initializeProjectProgressively() method that:

1. Processes files in chunks (default: 10 files per chunk)
2. Yields to the event loop between chunks via setImmediateP()
3. Sends diagnostics immediately per file — users see results appearing progressively
4. Cancels gracefully if:
   • The project is closed during initialization
   • A new diagnostics request arrives (e.g., user starts typing)
   • Another progressive init is started (e.g., project reloads)

Before (blocking refresh):
  Analysis → [refreshDiagnostics: ALL FILES EVENT] → sendPendingDiagnostics
              (single burst of work scheduled)

After (progressive):
  Analysis → [chunk 1] → yield → [chunk 2] → yield → ... → Done
              ↑                    ↑
      (UI responsive, LSP requests served between chunks)

Cancellation Integration

Progressive initialization integrates with the existing diagnostics system:

• When triggerDiagnostics() is called (file opened/changed), any ongoing progressive init is cancelled via progressiveInitCancelled flag
• This prevents stale startup diagnostics from overwriting fresher results
• The pattern mirrors the existing diagnosticsTimeout cancellation logic

Changes

Impact

• UI remains responsive during project startup
• Diagnostics appear progressively — first results visible within seconds
• No change to final state — all open files get diagnostics, same as before
• Minimal code change — single file, no API changes

Testing

• All language service tests pass (modern + legacy): //packages/language-service/...
• All LSP integration tests pass: //vscode-ng-language-service/integration/lsp:test
• All server unit tests pass: //vscode-ng-language-service/server/src/tests:test
• Tests implicitly validate responsiveness (would timeout if event loop blocked)

Breaking Changes

None. This is an internal optimization that doesn't change observable behavior.

Related

Complements:

• feat(language-service): implement pull-based diagnostics (LSP 3.17) #66700 (Pull-Based Diagnostics)
• perf(language-service): lighter analysis trigger for project initialization #66964 (Lighter Analysis Trigger)
• feat(language-server): Support client-side file watching via `onDidCh… #66668 (Client-Side File Watching)

AI Disclosure

This PR was developed using Claude Opus 4 AI assistant under human orchestration and review by @kbrilla.

Integration

See #66967 for integration with Pull-Based Diagnostics, which optimizes progressive init to use workspace/diagnostic/refresh instead of computing and pushing diagnostics when the client supports pull-based diagnostics.