feat(my-wordpress): add server-side search to entity list views

[epeicher]

Summary

Adds a search input above the Posts / Pages / Users / Media (and any plugin-registered) entity list views in the My WordPress window. Mirrors the visual treatment of the Content Graph search input so the two surfaces read as the same control — but the implementation diverges:

• Server-side, not client-side. Every WP REST collection supports ?search=… natively against indexed columns (post_title + post_content, user_login/email/nicename/display_name, attachment title/filename). Client-side filtering would only match the ~24–48 tiles in memory at any moment, which would be useless for paginated infinite-scroll lists.
• Atomic swap, not skeleton flash. Previous results stay visible (dimmed) while the new page resolves, then replace in a single frame. No "intermediate page" between keystrokes.

What's in here

• renderListToolbar — shared helper (300ms debounce, native-X clear, Enter-to-commit) consumed by all three built-in list renderers.
• REST plumbing — fetchEntityList, fetchUserList, fetchMediaPage gain optional search + signal params. No new endpoints, no PHP changes.
• Race guards — AbortController per page fetch + a stale-query check so fast typing can't paint a previous query's tiles into the current grid.
• Per-entity remembered query — survives a click-into-detail-and-back round-trip; resets when switching entities (e.g. Posts → Pages).
• Empty-state copy — `No match "".` for zero-result searches.
• TileLayout.clear() — small new method so the canvas can be reused for a fresh result set without disposing and rebuilding the layout instance.

UX notes

• Placement: own row below the breadcrumb header (full width, predictable space, room for future filter / sort controls). The Content Graph toolbar lives in the same spot for the same reasons.
• Dimming during in-flight searches uses opacity: 0.45 + 120ms ease-out on --searching. The title-bar activity pulse (free from trackedFetch) carries the rest of the "work in progress" feedback.
• Search query persistence is per-entity, in-memory only. Closing and reopening the window resets it.

Performance

• One REST round-trip per debounced keystroke, payload shape identical to a normal list fetch.
• No client-side index, no bundle-size hit beyond the helper (~80 LOC).
• Caveat: /wp/v2/posts?search=foo searches title + content. post_title is indexed, post_content is not (no FULLTEXT). Fine at typical site sizes; can get slow on very large content. Out of scope for v1.

Test plan

• Type in the search field on Posts — results refine without skeleton flash.
• Type fast (race scenario) — only the final query's results paint.
• Native search-input X clears immediately, no 300ms debounce wait.
• Empty result — shows `No posts match "xyz".`.
• Click into a post, back out — search query persists.
• Switch Posts → Pages — search field resets.
• Same flow on Users.
• Same flow on Media.
• Reorder / dock collapse / window resize while a search is in flight — no stale paints.

[github-actions]

✅ WordPress Plugin Check Report

✅ Status: Passed

📊 Report

All checks passed! No errors or warnings found.

---

🤖 Generated by WordPress Plugin Check Action • Learn more about Plugin Check