[bidi] setFiles tests assert only on the input value, never that the file was uploaded (all bindings)

## Feature and motivation

Every binding's `input.setFiles` test asserts only on the file input's `value` property. That shows the filename string was accepted; it does not show the file was attached or that its bytes were transmitted. A `setFiles` implementation that sent the filename but dropped the file would pass all of these tests.

The classic upload tests do prove the round trip — they submit the form and assert on what the upload endpoint echoed back into the target iframe, e.g. `py/test/selenium/webdriver/common/upload_tests.py:41-48` and the corresponding tests in the other bindings.

Current `setFiles` tests, all `value`-only:

- Java — `java/test/org/openqa/selenium/bidi/input/SetFilesCommandTest.java`
- Ruby — `rb/spec/integration/selenium/webdriver/bidi/protocol/input_spec.rb`
- JS — `javascript/selenium-webdriver/test/bidi/setFiles_command_test.js`
- .NET — `dotnet/src/webdriver/BiDi/Input/InputModule.cs` (consumers)

#18007 adds round-trip coverage on the Python side (`set_files`, submit, then assert the endpoint echoed back both the filename and the file content) plus a test that types into a text field and attaches a file in one flow. This issue is the parity follow-up for the other bindings.

## Things to consider

- The shared `common/src/web/upload.html` fixture has a file input and a submit button but no text field, so a combined type-and-upload test needs either a different fixture or a change to that one. I avoided changing it in #18007 — see the next point.
- `java/test/org/openqa/selenium/environment/webserver/UploadHandler.java` reuses a single `values` map across all multipart parts (line 59: `values` is created once outside the loop, and `allParts.add(values)` adds the same reference repeatedly). Adding another form part to `upload.html` would therefore concatenate that part's content into what the handler returns, probably breaking Java's existing upload assertions. Worth fixing that handler first if we want a shared fixture with more than one field. Note the Python test server (`py/test/selenium/webdriver/common/webserver.py:177-202`) echoes the whole multipart body instead, so it does not have this problem — the two servers behave differently here.
- Asserting on the file *content* rather than only the filename is what makes these tests non-vacuous. In #18007 I verified this by temporarily passing an empty file list and confirming the test fails; worth doing the same when porting.
- Also worth deciding whether these belong next to each binding's existing BiDi input tests or alongside its classic upload tests.