a11y: server-search announcements fire after the dropdown has closed

[gnbm]

This applies to the live-region work introduced in #485, not to 1.3.0. master makes no announcements at all, so it is not reproducible on the released build.

What happens

On an instance using onServerSearch: type into the search box, then close the dropdown (Escape, or a click outside) before the debounce elapses.

1. Roughly searchDelay ms after the dropdown has closed, the live region announces loadingText ("Loading results").
2. When the host responds, the live region announces the result count ("N results available").

Two announcements for an interaction the user did not make, describing a dropdown that is no longer open.

Why

closeDropbox() ends with setSearchValue(''). The value changes, so afterSetSearchValue() runs, and on a server instance it schedules a fetch:

afterSetSearchValue() {
  if (this.hasServerSearch) {
    clearTimeout(this.serverSearchTimeout);

    this.serverSearchTimeout = setTimeout(() => {
      this.serverSearch();
    }, this.searchDelay);
  }
  ...
}

Both server announcements are effectively unguarded:

Site	Guard
serverSearch() → announce(this.loadingText)	none
setServerOptions() → announce(this.getResultsCountMessage())	isInitialized only

The local-search path already guards exactly this case, in announceSearchResults():

if (!this.isInitialized || !this.isOpened() || document.activeElement !== this.$searchInput) {
  return;
}

That guard exists because setSearchValue('') also runs on close and after a value is set, where announcing would read a stale count into the user's ear. The server path bypasses it.

Secondary, and pre-existing: the pending serverSearchTimeout is not cancelled on close, so the spurious fetch is issued as well.

Suggested fix

• Guard both server announcements the way announceSearchResults() guards the local one — isInitialized && isOpened() && !isClosing.
• Cancel serverSearchTimeout in closeDropbox(), which removes the wasted request at the same time.

Coverage

No e2e spec currently drives server search — onServerSearch and setServerOptions appear in none of the 25 specs — so this behaviour is pinned in neither direction. A fix should land together with the first server-search spec rather than on its own.