A pair of boards FE fixes

What does this MR do and why?

Two fixes:

1. Don't remount the filtered search on initial board load

   See these flakes:

   • https://gitlab.com/gitlab-org/gitlab/-/jobs/16438543108 [1:1:1:1:1] Unable to find link or button "Epic", 2026-09-11
   • https://gitlab.com/gitlab-org/gitlab/-/jobs/16438199963 [1:2:3:1:1] Unable to find link or button "Weight", 2026-09-11
   • https://gitlab.com/gitlab-org/gitlab/-/jobs/16436814462 [1:1:3:1:1] Unable to find link or button "Weight", 2026-09-11
   • https://gitlab.com/gitlab-org/gitlab/-/jobs/16435418870 [1:2:2:1:1] Unable to find link or button "Iteration", 2026-09-10

   Diagnosed based on this job's screenshot: the board is loaded, input unfocused, no suggestions:

   

2. Handle creating a board before the boards list has loaded

   This doesn't occur in CI 'cause every spec that creates a board waits for requests first, but it's locally producible: if you create a board before the list query finishes, you can get stuck with a "Unable to save your changes" in a modal you can't exit since sourceData comes back as null!

These are such borderline "bugs" that I'm calling them typemaintenance since these will benefit us more in CI than anything else.

Discovered via Remove all uses of `wait_for_requests`, `wait_f... (&22879).

MR acceptance checklist

Evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.