fix(test-plans): mitigate scheduled e2e-autotest flakiness

Triage of the last 8 scheduled e2e-autotest runs identified three failure
categories: a real plan bug, LLM screenshot-based false downgrades, and
real timing flakes. This change addresses all three.

Category A — real plan bug
* java-pack-help-center-webview was missing vscjava.vscode-java-pack from
  setup.extensions. On scheduled runs (no PR VSIX) java.welcome was
  unregistered and the open-help-center step silently timed out. This was
  the #1 failure across the last 8 nightly runs (7/8). Now installs the
  pack from the marketplace on schedule runs while still letting --vsix
  override on PR runs.

Category B — LLM downgrade noise on ls-ready
* Add skipLlmVerify: true (introduced in @vscjava/vscode-autotest 0.7.5) to
  every ls-ready step that has no structured verify* field. The
  waitForLanguageServer action is itself the authoritative deterministic
  check; the LLM was downgrading these whenever the status bar still showed
  background indexing ("Java: Searching... 0%"), even though the LS was
  fully functional. Affected: java-dependency-viewer, java-extension-pack,
  java-fresh-import, java-maven-resolve-type, java-maven,
  java-new-file-snippet, java-single-file, java-webview-migration.

Category C — real timing flakes
* java-test-runner: bump wait-test-discovery from 45s to 90s (the
  vscode-java-test discovery scan can take longer than 45s on a cold cache)
  and add retries: 1 to run-all-tests so a discovery-still-warming first
  invocation can retry.
* java-maven-resolve-type: add retries: 1 to save-after-resolve so a slow
  Maven re-import on a cold cache (where the LS hasn't yet republished
  zero-errors at the time of save) can retry instead of failing the plan.

Plans whose flaky steps already carry a structured verify* field (e.g.
verify-completion with verifyCompletion: { notEmpty: true },
save-after-organize with verifyFile, verify-help-center-content with
verifyWebview) no longer need plan changes because the framework
auto-skip in @vscjava/vscode-autotest 0.7.5 already short-circuits the
LLM re-check whenever any structured verifier is present.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Author: wenytang-ms

test-plans/java-dependency-viewer.yaml

@@ -28,6 +28,11 @@ steps:
   - id: "ls-ready"
     action: "waitForLanguageServer"
     verify: "Java workspace has loaded; Explorer shows the project tree and Problems panel is settled"
+    # waitForLanguageServer is the authoritative deterministic check — the
+    # status bar can still flicker "Java: Searching... 0%" for background
+    # indexing right after the LS reports ready, which has historically
+    # caused LLM screenshot downgrades. Skip LLM here.
+    skipLlmVerify: true
     timeout: 120
 
   # ── Open dependency view ─────────────────────────────────

test-plans/java-extension-pack.yaml

@@ -30,6 +30,9 @@ steps:
   - id: "ls-ready"
     action: "waitForLanguageServer"
     verify: "Java workspace has loaded; Explorer shows the project tree and Problems panel is settled"
+    # waitForLanguageServer is the authoritative deterministic check —
+    # status-bar background indexing can cause spurious LLM downgrades.
+    skipLlmVerify: true
     timeout: 120
 
   # ── Trigger Classpath configuration command ──────────────

test-plans/java-fresh-import.yaml

@@ -45,6 +45,9 @@ steps:
   - id: "ls-ready"
     action: "waitForLanguageServer"
     verify: "spring-petclinic project has been imported; Java extension is activated and ready for editing"
+    # waitForLanguageServer is authoritative — skip LLM screenshot re-check
+    # (status bar background indexing causes false downgrades).
+    skipLlmVerify: true
     timeout: 300
 
   # ── Verify completion ────────────────────────────────────

test-plans/java-maven-resolve-type.yaml

@@ -49,6 +49,8 @@ steps:
     action: "waitForLanguageServer"
     verify: "maven-resolve-type project has been imported; the Java extension is activated and pom.xml is visible in the Explorer"
     timeout: 180
+    # waitForLanguageServer is authoritative — skip LLM screenshot re-check.
+    skipLlmVerify: true
 
   # ── Open Java file ──────────────────────────────────────
   - id: "open-app"
@@ -161,6 +163,10 @@ steps:
       errors: 0
     waitBefore: 20
     timeout: 90
+    # Maven re-import on a cold cache can take significantly longer than the
+    # waitBefore window; a single retry (with the LS likely already settled
+    # by then) recovers without inflating the happy-path wait further.
+    retries: 1
 
   # After save, the language server publishes diagnostics (status bar updates
   # to 0 errors, verified deterministically above). However, on Linux runners

test-plans/java-maven.yaml

@@ -30,6 +30,8 @@ steps:
   - id: "ls-ready"
     action: "waitForLanguageServer"
     verify: "Maven workspace has loaded; the Java extension is initialized and pom.xml is visible in the Explorer (the Problems panel may briefly show diagnostics that are still being recomputed after import)"
+    # waitForLanguageServer is authoritative — skip LLM screenshot re-check.
+    skipLlmVerify: true
     timeout: 120
 
   # ── Step 2: Open Java file and verify editing experience ─────────────────

test-plans/java-new-file-snippet.yaml

@@ -28,6 +28,8 @@ steps:
   - id: "ls-ready"
     action: "waitForLanguageServer"
     verify: "Java workspace has loaded for the simple-app project; no error notifications visible"
+    # waitForLanguageServer is authoritative — skip LLM screenshot re-check.
+    skipLlmVerify: true
     timeout: 120
 
   # ── Step 9: Create new Java file ─────────────────────────────

test-plans/java-pack-help-center-webview.yaml

@@ -13,6 +13,13 @@ description: |
 
 setup:
   extension: "redhat.java"
+  # The Help Center webview lives in vscode-java-pack itself. On scheduled
+  # runs there is no built VSIX, so the pack must be installed from the
+  # marketplace; otherwise the `java.welcome` command is unregistered and
+  # the open-help-center step times out silently. On PR runs the
+  # build-pack job's VSIX takes precedence (--vsix overrides marketplace).
+  extensions:
+    - "vscjava.vscode-java-pack"
   vscodeVersion: "stable"
   timeout: 60
   settings:

test-plans/java-single-file.yaml

@@ -31,6 +31,8 @@ steps:
   - id: "ls-ready"
     action: "waitForLanguageServer"
     verify: "Java extension has activated for the single-file workspace; no error notifications are visible"
+    # waitForLanguageServer is authoritative — skip LLM screenshot re-check.
+    skipLlmVerify: true
     timeout: 120
 
   # ── Step 2: Open Java file ──────────────────────────────

test-plans/java-test-runner.yaml

@@ -52,7 +52,7 @@ steps:
   # ready — discovery is asynchronous and Test Explorer is initially empty.
   # On cold-cache CI runners 20s is sometimes too short; bump to 45s.
   - id: "wait-test-discovery"
-    action: "wait 45 seconds"
+    action: "wait 90 seconds"
 
   # ── Step 2: Run tests via Java Test Runner palette command ───────
   # autotest 0.7.1 ships `openTestExplorer`/`runAllTests` actions wired to
@@ -72,6 +72,11 @@ steps:
     action: "run command Java: Run Tests"
     verify: "Java: Run Tests command has been invoked from the palette; the Java Test Runner extension has responded (this may show as a Testing view becoming active, a run indicator in the status bar, or an informational notification such as 'No tests found in this file' if discovery is still in progress — all of these indicate the command executed successfully)"
     waitBefore: 3
+    # Test discovery is asynchronous in vscode-java-test; on cold-cache
+    # CI runners the first Run Tests invocation can land before discovery
+    # completes ("No tests have been found"). Allow one retry — by the
+    # second attempt the discovery cache is usually warm.
+    retries: 1
 
   - id: "wait-test-complete"
     action: "wait 45 seconds"

test-plans/java-webview-migration.yaml

@@ -55,6 +55,10 @@ steps:
   - id: "ls-ready"
     action: "waitForLanguageServer"
     verify: "Maven salut workspace has loaded; the Java extension and the pack webview commands are ready"
+    # waitForLanguageServer is authoritative — skip LLM screenshot re-check
+    # (status bar may still show "Java: Searching... 0%" for background
+    # indexing right after the LS reports ready).
+    skipLlmVerify: true
     timeout: 180
 
   # ══════════════════════════════════════════════════════════════════════