Converge the visual Design Files prelude instead of clicking once (#6181)

`Playwright visual (settings-workspace)` went red on `[P2] captures the settings
BYOK surface` with a 10s `aria-selected` timeout: the Design Files tab sat at
`false` for all 23 polls with nothing re-clicking it. Seven other captures run
this identical prelude and passed, including the two neighbouring BYOK cases.

The defect is in the oracle, not the product. `prepareVisualWorkspaceFileList`
decided **once** whether to click — one instantaneous `isVisible()` probe of a
file row — and then asserted a state nothing retries. Any interleaving where the
workspace's own tab reconciliation lands around that single click leaves the
assertion permanently unsatisfiable for that attempt, and the lane runs
`OD_PLAYWRIGHT_FULLY_PARALLEL=1` with `retries: 0`, so it reports as a hard
failure rather than a flake.

`activateVisualDesignFilesTab` now converges on the goal state via `toPass`,
driving off `aria-selected` directly rather than through the file-row proxy —
the guard and the assertion were about different things even though
FileWorkspace derives both from one `activeTab === DESIGN_FILES_TAB` expression.
Repeat clicks are safe: the tab's handler is `setPersistedActive(DESIGN_FILES_TAB)`,
which is idempotent.

Why this is not a product regression from #6162: nothing in it touches tab
selection, tab persistence, or row visibility. Its only `design-files.css` change
deletes the hover cover-zoom, which cannot affect visibility, and a diff of
`apps/web/src` for `localStorage|activeTab|openTabs|restoreTab` comes back empty.
The lane's one green run before this failure (`4a6653186`, the #6174 repair of
the unrelated #5971 BYOK rename) is the whole basis for calling the baseline
clean.

Scope is the visual lane only — every caller is in `visual.ts` or
`visual-*.test.ts`, so the UI P0 lanes are untouched.

Author: lefarcen

e2e/lib/playwright/visual.ts

@@ -679,12 +679,33 @@ export async function gotoVisualWorkspace(page: Page): Promise<void> {
   await prepareVisualWorkspaceFileList(page);
 }
 
+/**
+ * Drive the workspace onto its Design Files tab, converging on that state
+ * instead of deciding once whether to click.
+ *
+ * `aria-selected` and the design-file rows both come off FileWorkspace's single
+ * `activeTab === DESIGN_FILES_TAB` expression, so probing the rows to decide
+ * whether to click was never asking the wrong question — the problem is that the
+ * answer can still change after the probe. The tab is *persisted*
+ * (`setPersistedActive`) and restored asynchronously, so a restore that lands
+ * after this helper's one click puts another tab back, and a one-shot helper has
+ * nothing left to re-click. Under the visual lane — fully parallel, `retries: 0`
+ * — that surfaced as a single capture timing out for 10s on `aria-selected`
+ * while its siblings, running this identical prelude, all passed.
+ *
+ * Clicking is safe to repeat: the tab's handler just sets the same active id.
+ */
+export async function activateVisualDesignFilesTab(page: Page): Promise<void> {
+  const tab = page.getByTestId('design-files-tab');
+  await expect(tab).toBeVisible({ timeout: T.medium });
+  await expect(async () => {
+    if ((await tab.getAttribute('aria-selected')) !== 'true') await tab.click();
+    await expect(tab).toHaveAttribute('aria-selected', 'true', { timeout: T.short });
+  }).toPass({ timeout: T.long });
+}
+
 export async function prepareVisualWorkspaceFileList(page: Page): Promise<void> {
-  const fileRow = page.getByTestId('design-file-row-index.html');
-  if (!(await fileRow.isVisible().catch(() => false))) {
-    await page.getByTestId('design-files-tab').click();
-  }
-  await expect(page.getByTestId('design-files-tab')).toHaveAttribute('aria-selected', 'true');
+  await activateVisualDesignFilesTab(page);
   // No pages dropdown to drive: 023937ef4 replaced the tab strip's pages
   // menu with a plain Design Files tab (#5517), deleting
   // `workspace-pages-menu-trigger` from the app and this helper alike. The