feat(network/onion): detect liveness via TcpStream close

[jetjinser]

What problem does this PR solve?

Issue Number: close #5161

Problem Summary:

The onion service currently polls the Tor daemon every 3 seconds via get_uptime() to detect connection loss. This adds unnecessary latency (up to 3s for failure detection) and constant I/O overhead. A passive, event-driven approach would react instantly and reduce resource usage.

P.S. This implementation represents the cleanest approach I could devise given the constraints of the existing torut controller API. If there is a more idiomatic or efficient way to monitor the underlying TcpStream liveness, I am open to feedback and happy to revise this PR accordingly.

What is changed and how it works?

What's Changed:

• Introduced tokio::io::duplex as an in-memory proxy between TcpStream and the TorControl.
• Spawned a background task that performs bidirectional copy between the TCP socket and the duplex stream.
• An mpsc channel notifies TorController when either copy direction terminates (EOF or error).
• Replaced the 3-second ticker loop in OnionService with a branch awaiting wait_for_disconnect().

Related changes

Check List

Tests

• Unit test
• Integration test
• Manual test (add detailed scripts or steps below)
• No code

Manual test steps:

1. ckb run with config listen_on_onion = true.
2. Observe the onion service starts successfully.
3. Kill/exit the Tor process.
4. Verify the node logs "Tor control connection lost" within milliseconds, not after a multi-second delay.
5. Restart the Tor daemon and verify the onion service can be re-established.

Side effects

• Performance regression
• Breaking backward compatibility
• Few more memory consumption

[eval-exec]

UnauthenticatedConn<_>

Could UnauthenticatedConn replace _ with the real inner type?