[route]

Fixes #676.

Problem

#644 replaced the blocking websocket write with write_nonblock + IO.select, so a browser that stops reading couldn't block the sending thread forever while it held the send lock. On JRuby that deadlocks: IO#readpartial waits in a NIO select holding the channel's blocking lock, and write_nonblock/IO.select need the same lock to switch the channel to nonblocking mode. The reader thread is parked in readpartial before the handshake is written, so Ferrum::Browser.new hangs forever. It's not only the handshake: any later write waits until the browser happens to send something.

Change

• Revert fix(client): give up on a websocket write the browser doesn't take #644.
• Frames are written by a dedicated writer thread. Callers and the driver only encode frames under the lock and queue them; the writer is the only code writing the socket and the reader the only code reading it, both with plain blocking calls. No lock is held across socket I/O, and the reader keeps delivering responses and events while a write is stuck.
• Each queued frame carries its command's deadline and is dropped if that passes before it's written, so a command queued behind a large one fails after its own timeout:, not the large one's.
• Connection health is separate from command timeouts: frames go out in 64KB chunks, and a chunk the browser takes no data of for protocol_timeout closes the connection. Commands still waiting get DeadBrowserError with the reason. A shorter pause doesn't kill the connection anymore.
• Restores the rest of fix(client): give up on a websocket write the browser doesn't take #644: the command timeout is passed down to the websocket, and a pending command whose send raised is forgotten.

Behavior changes

• A command whose own timeout expires while its frame is being written raises TimeoutError at that timeout. The frame can't be cut off midway, so it still goes out if the browser resumes, and the late response is ignored, as for any timed-out command.
• Client::WebSocket#send_message returns once the frame is queued.

JRuby in CI

• The test matrix runs on jruby with Java 21. rbs is installed on MRI only, it doesn't build on JRuby.
• The test server is stopped after the suite: on JRuby Puma's reactor isn't interrupted by the kill at exit, so the process never exited.
• The websocket test proxy pipes with readpartial/write instead of IO.copy_stream from two threads, which hit the same JRuby lock.
• browser.pages, windows(:last) and workers came back in random order on JRuby: targets were kept in a Concurrent::Map, which is an insertion-ordered Hash on CRuby but a hash-ordered Java map on JRuby. They're kept in a Concurrent::Hash now.