fix: explicitly send input_reply via wsclient when stdin_hook is invoked

[Nwokike]

Summary

When executing non-interactive code with allow_stdin=True and providing a custom stdin_hook to ColabRuntime.execute_code, any user input captured by the hook causes the kernel execution to stall indefinitely waiting for an input_reply WebSocket message.

Root Cause

In wrapped_stdin_hook (src/colab_cli/runtime.py), after original_stdin_hook returns the user's input string (res), execute_interactive (jupyter_kernel_client.wsclient) simply loops (continue) without sending input_reply. It expects whoever intercepted stdin_request to send the input_reply back to the kernel.

Previously, wrapped_stdin_hook did not explicitly construct and transmit input_reply over wsclient.stdin_channel (or attempted to call self.kernel_client.input(res), which fails because KernelClient does not have an .input() method — .input() and .stdin_channel belong to _manager.client (KernelWebSocketClient)).

Solution

This PR updates wrapped_stdin_hook so that after obtaining the response from original_stdin_hook:

1. It accesses wsclient = self.kernel_client._manager.client.
2. Constructs the input_reply message dictionary and attaches the parent_header from the incoming stdin_request prompt (prompt["header"]) so the kernel properly correlates the reply to the request.
3. Transmits the reply over wsclient.stdin_channel.send(reply_msg).
4. Falls back to self.kernel_client.input(res) if present.

This ensures all custom stdin_hook implementations (e.g. interactive UI dialogs, custom terminal input bridges) reliably resume remote execution after handling input()/getpass() prompts.