[#1124 followup] command-palette typing-search 'banResults' not visible on mobile-chromium

[rumblefrog]

Symptom

web/tests/e2e/specs/flows/ui/command-palette.spec.ts:110 — typing surfaces a seeded ban — fails reliably on the mobile-chromium project (chromium project passes deterministically). Both the original 14-char prefix shape and the post-#1205 full-unique-nick shape hit the same wall:

✘ specs/flows/ui/command-palette.spec.ts:110:9 [mobile-chromium]
  Error: expect(locator).toBeVisible() failed
  Locator: locator('[data-testid="palette-result"][data-result-kind="ban"]').first()
  Timeout: 5000ms
  Error: element(s) not found

This is the only test that surfaced after #1205 turned failOnFlakyTests: true and dropped CI to workers: 1. The entire rest of the suite (87 tests including the same spec on chromium and the enter subtest on mobile-chromium) passes deterministic green.

What's been ruled out

• Cross-process truncate race: fixed by the GET_LOCK in Sbpp\\Tests\\Fixture::truncateAndReseed (fix(tests): serialize Fixture truncate+reseed; fail loudly on flaky CI #1205).
• Cross-worker DB races: fixed by workers: 1 in CI (fix(tests): serialize Fixture truncate+reseed; fail loudly on flaky CI #1205).
• Search result paging by older sibling tests: fixed by typing the full unique nick instead of a 14-char prefix (fix(tests): serialize Fixture truncate+reseed; fail loudly on flaky CI #1205); collapses the search to exactly one matching row.
• Debounce + cold-runner I/O timing: fixed by gating on the dialog's data-loading flag with a 10s timeout (fix(tests): serialize Fixture truncate+reseed; fail loudly on flaky CI #1205); data-loading clears, then we still don't see results.
• .sidebar__link hidden on mobile: there's no media-query in theme.css hiding the class.
• Server-side filter: bans.search returns no early-empty for non-empty queries; LIKE '%full-unique-nick%' should match the just-inserted row.

Likely shape of the bug

Something specific to the mobile-chromium project (iPhone 13 device descriptor, defaultBrowserType: 'chromium', viewport 390×844) interacts with the palette dialog's <dialog> rendering or the post-fill input handling so the bans.search either:

1. doesn't actually land a request (the click on data-loading clears because the helper deletes the attribute on "no envelope" too), or
2. lands and returns rows but the rendered <a data-testid=\"palette-result\"> isn't laid out inside the visible dialog rect (so Playwright's toBeVisible() returns false), or
3. lands but the <dialog> has been closed/re-opened by some mobile-specific keyboard handling between the assertions.

Investigation paths:

• Add a page.waitForResponse(POST /api.php with action: 'Bans.Search') and inspect data.bans.length directly to disambiguate (1) from (2)/(3).
• Pull a Playwright trace from CI (trace: 'on-first-retry' already on) and look at the DOM snapshot at the failed assertion.
• Reproduce locally with ./sbpp.sh e2e --project=mobile-chromium --grep \"typing surfaces a seeded ban\".

Workaround in #1205

The test is conditionally skipped on mobile-chromium with a comment pointing at this issue:

```ts
test.skip(testInfo.project.name === 'mobile-chromium', 'tracked in #');
```

Chromium coverage of the same surface remains. Removing the skip is the success criterion for closing this issue.

Refs

• fix(tests): serialize Fixture truncate+reseed; fail loudly on flaky CI #1205 — flaky-tolerance + truncate-race fix that surfaced this.
• Add Playwright E2E test suite for the modernized web panel #1124 — Slice 6, originating spec.
• Modernize the default web panel theme (2026 redesign) #1123 — testability hooks contract this should latch onto.

[rumblefrog]

Update: the enter sibling subtest (focused result + Enter navigates to the ban-list anchor) shares the same root cause and same intermittent failure mode on mobile-chromium. After skipping just type, the next CI run on #1205 surfaced enter failing with the identical assertion error:

```
✘ command palette › focused result + Enter navigates to the ban-list anchor (mobile-chromium)
Error: expect(locator).toBeVisible() failed
Locator: '[data-testid="palette-result"][data-result-kind="ban"]' filtered by hasText: seed.nick
Timeout: 5000ms
```

Both subtests exercise the same surface (typing → bans.search → result <a> visible). The 'open/Esc' sibling doesn't search and continues to pass on mobile-chromium, so the issue is firmly the typing-search render under the iPhone-13 device descriptor, not the palette dialog itself.

#1205 now skips both type and enter on mobile-chromium. Removing both skips is the success criterion for closing this issue.