[py][bidi] input.setFiles has no file detector, so local paths do not work against a remote browser

## Feature and motivation

BiDi `input.setFiles` has no equivalent of the classic file detector, so attaching a local file to a file input does not work when the browser is on another machine (Grid, Docker, cloud provider). This is a functional gap between classic and BiDi, not just a coverage gap.

Under classic, `WebElement.send_keys` on a remote driver runs the given paths through `file_detector` and uploads each one to the node before dispatching the keys:

https://github.com/SeleniumHQ/selenium/blob/trunk/py/selenium/webdriver/remote/webelement.py#L263-L274

So this works against a remote browser today:

```python
driver.find_element(By.ID, "upload").send_keys("/path/on/my/laptop/test_file.txt")
```

Under BiDi, `input.setFiles` sends the raw path straight through to the browser, which resolves it on the *browser host*. There is no upload step and no detector hook, so the same call against a remote browser either fails or silently attaches nothing:

```python
driver.input.set_files(driver.current_window_handle, element_ref, ["/path/on/my/laptop/test_file.txt"])
```

This came out of reviewing the Python BiDi interaction code (#18007). It is not Python-specific — Java, Ruby, JS, and .NET all pass paths through to `setFiles` unchanged, so whatever we decide should apply across bindings.

## Things to consider

- The existing `setFiles` tests never catch this: they all run against a local browser and assert on the input's `value`. The new round-trip tests in #18007 are also local-only. A remote-specific test would be needed either way.
- Whether the fix belongs in the bindings (detect a local path, upload it via the classic `/session/{id}/file` endpoint, then pass the returned remote path to `setFiles`) or whether BiDi should grow a file-transfer primitive of its own. The former works today but means a BiDi call depends on a classic endpoint, which is awkward for a BiDi-only future.
- Whether `setFiles` should respect `driver.file_detector` at all, or whether users should be expected to place files on the browser host themselves. If the latter, we should document that clearly, because the classic behaviour sets the opposite expectation.
- Spec question: whether this should be raised with the WebDriver BiDi spec rather than solved per-binding.

Filing so the decision is recorded rather than discovered by users migrating from classic to BiDi.