fix: decouple no-config debug readiness from core activation

[wenyt (wenytang-ms)]

Summary

Follow-up to #1690: register core Java Run/Debug support without waiting for optional No-Config Debug initialization.

The previous fix isolates storage failures and adds an opt-out, but activation still waits for endpoint setup, Java executable discovery, and wrapper permission preparation. Those steps are not prerequisites for registering standard launch.json Run/Debug support.

Design

• Register core Java debugging first, then eagerly start No-Config Debug preparation as an owned background task. Extension activation returns without waiting for that task.
• Share one initialization result with debug_java_application. The tool waits before reading launch inputs, probing Java, emitting launch telemetry, building, opening terminals, or stopping an existing session.
• Limit each readiness wait to 60 seconds and honor caller cancellation. Cancelling or timing out one invocation does not cancel initialization or other callers; later invocations can retry the same task.
• Return distinct guidance for disabled, failed, timed-out, cancelled, or disposed initialization instead of attempting to launch.
• Add the registration to extension subscriptions immediately. Dispose partially created listeners synchronously on shutdown and guard asynchronous continuations against publishing environment updates, creating listeners, starting an attach, or deleting endpoint data after disposal. Already-started filesystem operations and Java extension activation are not forcibly interrupted.
• Handle background initialization failures at the task boundary, clean up partial resources and feature environment contributions, and surface a sanitized error code.

Compatibility and limits

The default-enabled opt-out and activation-time setting snapshot are unchanged. Standard Run/Debug and existing-session AI tools remain available independently of No-Config readiness.

This does not change the wrapper's Java selection order (JAVA_HOME -> VSCODE_JAVA_EXEC -> PATH), the Java discovery fallback, or existing script-permission fallback behavior.

Terminal preparation remains eager, not lazy. Extension activation completing no longer means No-Config Debug is ready. Terminals opened too early may need to be recreated once preparation finishes; this PR does not promise to repair their environment or close them automatically. The root README and terminal/AI documentation describe this boundary.

Startup stale-file cleanup and file-based endpoint delivery are unchanged. This PR does not fix the previously discussed cleanup race, redesign the request/recovery protocol, or add an AI launch.json fallback.

Validation

• npm run compile and targeted TSLint.
• Focused suites in a Windows VS Code 1.95.3 extension host: 68 passed, 1 POSIX-only test skipped, covering activation ordering, shared readiness, per-caller cancellation/timeout, failure reporting, disposal during directory/Java/script work, late attach callbacks, AI gating, and existing environment/storage behavior.
• A separate bundled-extension probe deliberately holds Java discovery pending. The old bundle fails the activation-deadline assertion; the new bundle registers ordinary Java configuration/adapter providers and commands, completes activation, keeps all 10 AI tools registered, and allows cancellation of the waiting AI launch before input access.

The separate probe stubs Java-extension discovery and AI-tool registration. It does not launch a real JVM or claim NixOS end-to-end coverage.

Related to #1689.

[azure-pipelines]

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