Prevent stale path selection while directory contents are loading

[GlazerMann]

Summary

A BatchConnect path-selector system test exposed a pre-existing race in directory navigation.

When a user clicks a directory, PathSelectorTable#reloadTable starts an asynchronous fetch(). The selected/last-visited path is not updated until that request completes, but the Select Path button remains usable while the request is pending. A fast click on Select Path can therefore submit the previously loaded directory instead of the directory the user just selected.

This is a production UI race, not just a Selenium timing issue: the footer remains interactive while directory navigation is pending. The flaky path_selector can hide files, only showing directories system test exposed that same window by clicking the directory and footer button back-to-back.

Changes

• Disable Select Path while a directory reload is in progress.
• Track only the current reload generation and ignore responses from older requests, so an earlier slow request cannot overwrite a newer directory choice.
• Re-enable Select Path only when the newest reload finishes.
• Update all three system-test paths that select directories to wait for the button to become enabled before selecting the path.
• Remove the fixed three-second sleep from path_selector works and preserve its existing assertion that the loading spinner is hidden after the reload completes.

Behavior and error handling

File selection remains unchanged because file clicks update the selected path synchronously and do not reload the table.

The existing error-display behavior is also preserved. resetTable() remains in the existing success/error paths rather than being moved into finally, so an error can still show #forbidden-warning without it immediately being hidden. After the newest reload succeeds or fails, Select Path is enabled again; stale responses do not alter the current table, warning state, or selected path.

In-flight requests are not aborted; older requests are allowed to complete, but their responses are ignored once a newer reload has started.

The implementation intentionally uses a single request-generation counter rather than maintaining a second loading-state flag. The button's native disabled state is the UI lock, avoiding duplicate state that could drift out of sync.

Why this is separate from #5829

This race was found while investigating a failed system-test job associated with #5829, but it is independent of the ChromeDriver detached-document workaround. This change does not broaden Selenium retries or alter Capybara error handling; it fixes the path selector's asynchronous UI state directly.

[GlazerMann]

The jobs failures are the problem fixed by #5815. Doing GUI testing with CI is really hard.