Java extension should retry activation when Red Hat Java extension is not yet ready

[djzager]

Problem

When loading in DevSpaces (or similar remote environments), the Konveyor Java extension and the Red Hat Java extension activate concurrently. The Red Hat Java extension often takes additional time to reach Standard mode. The Konveyor Java extension currently makes a single, synchronous check at activation time (extension.ts:72-100):

1. vscode.extensions.getExtension("redhat.java") — if not found, abort
2. await javaExt.activate() — single attempt, abort on failure

If the Red Hat Java extension isn't ready at that exact moment, the Konveyor Java extension fails to activate and never recovers. The user must reload the browser/window to trigger re-activation.

Current behavior

• Extension activation is one-shot: no retry, no polling, no event listeners
• Health checks (healthCheck.ts) detect the problem after the fact but can't trigger re-activation
• User must manually reload to recover

Expected behavior

The extension should gracefully handle the case where redhat.java is not yet ready at activation time, and automatically complete initialization once it becomes available — without requiring a window reload.

Essential minimum

Use vscode.extensions.onDidChange to defer provider registration when redhat.java is not active at startup:

1. If redhat.java is not found or not active during activate(), register a listener on vscode.extensions.onDidChange
2. On each change event, re-check vscode.extensions.getExtension("redhat.java") and whether it's active
3. Once active, proceed with the rest of initialization (LSP proxy, provider manager, core registration)
4. Add a reasonable timeout (e.g., 2-3 minutes) after which a notification is shown with a "Reload Window" action
5. Don't block — activate() should return normally, and the deferred init should run in the background

This is the simplest approach that avoids polling/timers and uses VS Code's built-in event. It does not require checking java.server.mode or any Red Hat Java internals.

Nice-to-have (opinions, not requirements)

• Show a progress notification while waiting (e.g., "Waiting for Java Language Server...") so users know something is happening, not broken
• Check java.server.mode — the Red Hat Java extension can report isActive: true while still in Lightweight mode. Checking mode would be more precise, but historically these APIs have been unreliable and fragile to depend on. If the Red Hat Java extension exposes a stable readiness signal, we could use it, but isActive is likely sufficient for the race condition described here
• Retry the full provider startup — if java-external-provider or the LSP proxy fails because the language server wasn't ready, those could also benefit from retry logic. But that's a separate, larger concern

Context

• Reported in the context of DevSpaces workshops where concurrent extension loading causes a race condition
• The older monolithic extension may have had java.server.mode checks but they were removed due to unreliability
• The current multi-extension architecture (core + java) was introduced in ✨ Create konveyor-java and konveyor-javascript extension #960