test(e2e): drop flaky LLM verify on expandTreeItem steps

The LLM screenshot check on expand-existing-pkg / expand-source-root /
expand-project is inherently flaky on already-expanded trees — the
recent CI run downgraded a mechanically-successful expand from pass to
fail, then immediately contradicted itself in the post-mortem analysis
('was already expanded before the action and remains expanded after').

The deterministic verifyTreeItem steps that follow each expand provide
authoritative ground truth: if the expand didn't happen, the child item
won't be visible. So the LLM verify lines are pure redundancy with no
upside and a non-trivial false-negative rate.

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

Author: wenytang-ms

test/e2e-plans/java-dep-refresh-generated-files.yaml

@@ -55,13 +55,15 @@ steps:
   - id: "wait-tree-load"
     action: "wait 3 seconds"
 
+  # NOTE: no `verify:` on expand steps — the LLM screenshot check is flaky
+  # ("LLM downgraded pass -> fail" on already-expanded trees). The next
+  # verifyTreeItem (or the chained expand below) provides authoritative
+  # ground truth: if the expand didn't happen the child won't be visible.
   - id: "expand-project"
     action: "expandTreeItem my-app"
-    verify: "my-app project expanded"
 
   - id: "expand-source-root"
     action: "expandTreeItem src/main/java"
-    verify: "source root src/main/java expanded"
 
   - id: "baseline-existing-pkg"
     action: "wait 1 seconds"
@@ -111,10 +113,11 @@ steps:
       visible: true
     timeout: 15
 
-  # Sanity: a new class in an existing package also appears.
+  # Sanity: a new class in an existing package also appears. No `verify:` here
+  # for the same reason as the expand steps above — check-existing-pkg-class
+  # below is the deterministic assertion.
   - id: "expand-existing-pkg"
     action: "expandTreeItem com.mycompany.app"
-    verify: "existing package com.mycompany.app expanded"
 
   - id: "check-existing-pkg-class"
     action: "wait 1 seconds"