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

* 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.

* fix(test-plans): restrict skipLlmVerify to G1/G4; add retries for cold-cache flakes

Reverts the over-broad framework auto-skip (any structured verify -> no LLM)
that was landed in autotest v0.7.5/0.7.6. LLM screenshot verification is the
anti-silent-pass safety net and must stay enabled on steps where the screenshot
carries unique signal (popup visibility, decoration lag, panel content).

Final policy:
  - skipLlmVerify=true on Group 1 (16 ls-ready steps): waitForLanguageServer
    polls the same status bar text the LLM would read, so LLM adds zero signal.
  - skipLlmVerify=true on Group 4 (3 disk-write steps: save-after-organize,
    add-gson-dependency, create-formatter-profile): action mutates a file not
    open in any editor; before/after screenshots are by-design identical and
    LLM always downgrades. verifyFile from disk is the authoritative signal.
  - retries: 1 on 8 verify-completion steps to mitigate cold-cache 'Loading...'
    LLM downgrades while keeping the screenshot check enabled.
  - retries: 1 on java-maven-resolve-type save-after-resolve (kept from prior
    commit) for Maven indexer warm-up.
  - Wait bump 45 -> 90s on java-test-runner wait-test-discovery (kept).
  - java-pack-help-center-webview setup.extensions hard-requires java-pack
    (kept) — fixes the real bug (5/8 failures).

LLM coverage preserved on verify-completion (popup visibility), verifyEditor
(guards against page-wide DOM stale-tab fallback), verifyProblems
(diagnostics red squiggle lag) and verifyWebview (visual rendering).

Requires autotest >= 0.7.7 to honor skipLlmVerify without the auto-skip side
effect.


* ci: retrigger E2E AutoTest against @vscjava/vscode-autotest@0.7.8

The 0.7.7 release did not actually honor skipLlmVerify because
planParser dropped the field on deserialize. 0.7.8 contains the
parser fix; this empty commit restarts CI so the matrix installs
the correct version.

Author: wenytang-ms

test-plans/java-basic-editing.yaml

@@ -48,6 +48,7 @@ steps:
   - id: "ls-ready"
     action: "waitForLanguageServer"
     verify: "Java extension has activated and the simple-app project tree is visible in the Explorer sidebar"
+    skipLlmVerify: true  # waitForLanguageServer reads the same status bar text the LLM would inspect
     verifyProblems:
       errors: 2
     timeout: 120
@@ -140,6 +141,10 @@ steps:
       path: "~/src/app/App.java"
       contains: "import java.io.File"
     timeout: 10
+    # Save All has no on-screen change (tab dirty dot clears on the saved
+    # tab but the active editor isn't the saved file). LLM downgrades on
+    # before==after by-design.
+    skipLlmVerify: true
 
   # ── Step 8: Rename Symbol (F2) ──────────────────────────────
   - id: "close-all-before-rename"

test-plans/java-debugger.yaml

@@ -44,6 +44,7 @@ steps:
     verify: "Java workspace has loaded; Problems panel shows no errors"
     verifyProblems:
       errors: 0
+    skipLlmVerify: true  # waitForLanguageServer is authoritative; LLM only sees the same status bar
     timeout: 120
 
   # ── Open App.java ────────────────────────────────────────

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 ────────────────────────────────────
@@ -67,3 +70,6 @@ steps:
     verifyCompletion:
       notEmpty: true
     waitBefore: 5
+    # LLM may downgrade if it sees "Loading..." spinner on cold cache; retry
+    # gives the LS a warmed cache so the popup is fully rendered.
+    retries: 1

test-plans/java-gradle-java25.yaml

@@ -36,6 +36,7 @@ steps:
     verifyProblems:
       errors: 0
     timeout: 300
+    skipLlmVerify: true  # waitForLanguageServer is authoritative; LLM only sees the same status bar
 
   # ── Step 2: Open Java file ───────────────────────────────
   # wiki: "Open Foo.java, make sure the editing experience is correctly working"
@@ -54,6 +55,8 @@ steps:
     verifyCompletion:
       notEmpty: true
     waitBefore: 8
+    # Retry once on cold-cache "Loading..." LLM downgrades.
+    retries: 1
 
   # ── Step 4: Verify editing ────────────────────────────────
   - id: "goto-line"

test-plans/java-gradle.yaml

@@ -36,6 +36,7 @@ steps:
     verifyProblems:
       errors: 0
     timeout: 300
+    skipLlmVerify: true  # waitForLanguageServer is authoritative; LLM only sees the same status bar
 
   # ── Step 2: Open Foo.java and verify editing experience ─
   # wiki: "Open Foo.java file, make sure the editing experience

test-plans/java-maven-java25.yaml

@@ -34,6 +34,7 @@ steps:
     verifyProblems:
       errors: 0
     timeout: 180
+    skipLlmVerify: true  # waitForLanguageServer is authoritative; LLM only sees the same status bar
 
   # ── Step 2: Open Java file ───────────────────────────────
   # wiki: "Open Bar.java, make sure the editing experience is correctly working"
@@ -52,6 +53,8 @@ steps:
     verifyCompletion:
       notEmpty: true
     waitBefore: 8
+    # Retry once on cold-cache "Loading..." LLM downgrades.
+    retries: 1
 
   # ── Step 4: Verify editing ────────────────────────────────
   - id: "goto-line"

test-plans/java-maven-multimodule.yaml

@@ -32,6 +32,7 @@ steps:
     action: "waitForLanguageServer"
     verify: "Multimodule Maven workspace has loaded; the Java extension is initialized for the project with module1 and module2 visible in the Explorer (the Problems panel may briefly show diagnostics that are still being recomputed after import — the verifyProblems checks below pin the final state)"
     timeout: 180
+    skipLlmVerify: true  # waitForLanguageServer is authoritative; LLM only sees the same status bar
 
   # ── Step 2: Verify module1 Foo.java ──────────────────────
   # wiki: "make sure the editing experience is correctly working
@@ -48,6 +49,8 @@ steps:
     verifyCompletion:
       notEmpty: true
     waitBefore: 8
+    # Retry once on cold-cache "Loading..." LLM downgrades.
+    retries: 1
 
   # Close module1's tab first so the next `open file Foo.java` request
   # disambiguates to module2/Foo.java rather than re-focusing the already-
@@ -69,3 +72,5 @@ steps:
     verifyCompletion:
       notEmpty: true
     waitBefore: 8
+    # Retry once on cold-cache "Loading..." LLM downgrades.
+    retries: 1

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"
@@ -103,6 +105,10 @@ steps:
       path: "~/pom.xml"
       contains: "com.google.code.gson"
     waitBefore: 2
+    # Disk-only insertLineInFile: pom.xml isn't in any editor, so before/after
+    # screenshots are necessarily identical. LLM always downgrades; verifyFile
+    # reading from disk is the only meaningful signal.
+    skipLlmVerify: true
 
   # Re-open pom.xml so the AFTER screenshot shows the new <dependency>
   # block. Loading fresh from disk avoids any in-memory/disk mismatch.
@@ -161,6 +167,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