fix: decouple no-config startup and fail fast on AI launch readiness

[wenyt (wenytang-ms)]

Summary

Follow-up to #1690: keep optional No-Config Debug preparation off the core Run/Debug activation path, and make AI launch readiness fail fast instead of waiting up to 60 seconds.

Core Java configuration/adapter providers and commands are registered first. No-Config terminal preparation remains an owned, eager background task. The AI launch entry is registered immediately when the Java extension and Language Model API are available; its existing when: javaLSReady visibility condition is unchanged.

AI readiness contract

The launch tool observes the Java extension's api.serverReady() in the background and checks a synchronous snapshot of both Java readiness and No-Config terminal preparation on invocation. An active extension or serverMode: Standard alone is not treated as proof that JDT LS is ready.

Result	Meaning and recovery
JAVA_NOT_READY	JDT LS has not reported ready. Wait for Java startup; switch to Standard mode or import the project if required.
NO_CONFIG_NOT_READY	Java is ready, but terminal preparation is incomplete. Retry after preparation completes.
JAVA_INIT_FAILED	Java API activation/readiness failed, the API is unavailable, or the Java API reports an error. Follow the returned log/update/reload guidance.
NO_CONFIG_INIT_FAILED	No-Config initialization failed. Resolve the initialization problem before retrying.
NO_CONFIG_DISABLED	Enable the setting, reload VS Code, and recreate existing terminals if this integration is wanted.
NO_CONFIG_DISPOSED / CANCELLED	The tool or registration was disposed, or the caller cancelled. No launch is attempted.

These responses are returned without a readiness wait, launch-input access, launch-time Java probing, launch telemetry, builds, terminal changes, or stopping an existing session. There is no per-invocation readiness timer or launch queue. Becoming ready does not replay a refused invocation: the caller must make a new request.

AI guidance and the tool description explicitly distinguish startup prerequisites from project-code errors. Agents should report the prerequisite or continue independent work, not poll the launch tool, diagnose output from an older terminal, or bypass readiness with a terminal launch. Existing-session AI tools remain independently registered.

Lifecycle and compatibility

• Replace waitUntilReady() with a synchronous No-Config state snapshot while retaining the shared terminal-initialization result and immediate disposal ownership.
• Observe Java readiness once per launch-tool registration. Handle activation/readiness rejection with controlled, path-free failure messages, reflect known Java error status even if serverReady() stays pending, and ignore late completion after disposal.
• Fix the shared getJavaExtensionAPI() helper's async-Promise-executor bug so activation rejection propagates. Caller cancellation only stops that caller's wait, and cancellation listeners are released.
• Keep endpoint listeners ahead of Java discovery rather than delaying the terminal integration until JDT LS is ready. Directory preparation and stale-file cleanup run once per registration; successful-attach cleanup still runs per endpoint.
• Preserve the default-enabled opt-out and activation-time setting snapshot, diff-aware environment updates, Java selection order (JAVA_HOME -> VSCODE_JAVA_EXEC -> PATH), Java-discovery fallback, and existing script-permission fallback.
• Preserve synchronous cleanup of partial listeners and guards against late environment updates, listener creation, attach work, or endpoint deletion after disposal. Already-started filesystem operations and shared Java activation are not forcibly interrupted.

Activation completing still does not guarantee that No-Config terminal preparation is complete. Early terminals may need to be recreated; they are not automatically repaired or closed.

Startup stale-file reconciliation, the file-based endpoint protocol, and an AI launch.json fallback remain outside this PR. This does not claim to fix the previously discussed startup cleanup race.

Validation

• Restored dependencies from the PR lockfile with npm ci; no dependency versions or lockfile changes.
• npm run compile and targeted TSLint on all changed TypeScript files.
• Focused suites in a Windows VS Code 1.95.3 extension host: 102 passed, 1 POSIX-only test skipped. Coverage includes activation ordering, immediate readiness snapshots and responses, cancellation, failure precedence, no replay after readiness, real helper rejection propagation, disposal races, and existing storage/environment/endpoint behavior.
• A separate bundled-extension probe holds Java API activation, serverReady(), and endpoint-directory creation pending. Core providers/commands and all 10 AI tools register and activation completes. Direct calls return JAVA_NOT_READY, JAVA_INIT_FAILED, NO_CONFIG_NOT_READY, or CANCELLED within the probe deadline without reading inputs. After prerequisites complete, a fresh invocation enters the existing launch flow; earlier refusals are not replayed.

The tests/probe stub Java-extension behavior and AI-tool registration. The probe cancels before a real launch; no real JVM attach or NixOS end-to-end coverage is claimed.

Related to #1689.

[azure-pipelines]

Azure Pipelines:
There may be pipelines that require an authorized user to comment /azp run to run.