[py] add BiDi upload tests that verify files actually reach the server

[AutomatedTester]

Description

The Python BiDi suite already covers input.setFiles, but every one of those tests stops at reading the file input's value property. That only shows the filename string was accepted — it does not show the file was actually attached or that its bytes were transmitted. Classic py/test/selenium/webdriver/common/upload_tests.py goes further: it submits the form and reads what the upload endpoint echoed back into the target iframe. The BiDi tests had no equivalent, so BiDi uploads were less well covered than classic ones.

This adds three tests to py/test/selenium/webdriver/common/_bidi/input_tests.py:

• test_set_files_posts_file_to_server — mirrors classic test_can_upload_file. Calls set_files, clicks #go, switches into upload_target, and asserts the endpoint echoed back both the filename and the file's content. The content assertion is the load-bearing one: it can only appear if the bytes were really sent.
• test_set_files_posts_two_files_to_server — mirrors classic test_can_upload_two_files, asserting both files' distinct content markers.
• test_type_and_set_files_in_same_form — covers filling in a form the way a user actually does: type into a text field via BiDi key actions, then attach a file via set_files, then assert both survived. It also asserts #fileResults became "changed", so the file input's onchange handler has to fire — no existing BiDi test checks that a real change event is dispatched rather than just a value being written.

Motivation and Context

Came out of a review of the Python BiDi interaction code asking whether a user can type and upload under BiDi the same way they can under classic. Uploads were tested, but not to the same depth, and the type-plus-attach journey was not covered at all.

Worth noting for reviewers: the underlying setFiles tests in Java, Ruby, JS, and .NET also assert only on getAttribute("value"), so the same coverage gap exists in the other bindings. This PR only fixes Python; happy to file a parity follow-up.

I deliberately did not add a text field to common/src/web/upload.html. That would have let the type-and-upload test round-trip through the server too, but the fixture is shared with every binding, and the Java UploadHandler reuses a single values map across multipart parts (java/test/org/openqa/selenium/environment/webserver/UploadHandler.java:59), so an extra form part would concatenate into the content it returns and likely break Java's upload tests. Using formPage.html covers the same journey without that blast radius.

Types of changes

• Test additions (no change to shipped behaviour)

Checklist

• I have read the contributing document
• My change requires a change to the documentation — no
• I have added tests to cover my changes

Verification

• Full _bidi/input_tests.py (30 tests) green on Chrome and Firefox via bazel test //py:test/selenium/webdriver/common/_bidi/input_tests-{chrome,firefox}-bidi --cache_test_results=no.
• Negative check to confirm the new assertions are not vacuous: temporarily changed files=[file_path] to files=[] in the round-trip test and confirmed it fails with TimeoutException, then reverted.
• ruff format and ruff check clean.

AI assistance disclosure

Per CONTRIBUTING.md, disclosing for reviewer context: the three tests were drafted with Claude Code, then reviewed, run, and verified by me (including the negative check above). No Co-Authored-By tag for the tool, per the same policy.

Co-Authored-By: Copse noreply@copse.dev
Copse-Models: acp:claude-agent-acp#opus[1m]