[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.