Java SDK: getSessionCommandLogs WebSocket callbacks not fired for plain-text log frames (demux / stream state)

[BunnkeiKou]

Describe the bug
When streaming session command logs via Process.getSessionCommandLogs(sessionId, commandId, onStdout, onStderr), stdout/stderr callbacks may never run (or only flush at connection end) if the WebSocket payload is plain text without the demux byte markers. Under the same server/toolbox version, the Python SDK delivers incremental chunks to the log callbacks as expected.

This makes true streaming from Java unreliable compared to Python, even when the command runs successfully and the server is sending data.

To Reproduce

1. Create a session and run a long-running shell command that only prints to stdout, e.g.

for i in {1..10}; do echo "tick-$i"; sleep 1; done with run_async=true.

2. Subscribe with Java: process.getSessionCommandLogs(sessionId, cmdId, onStdout, onStderr).

3. Observe server/toolbox logs or client-side logging: no onStdout invocations per second; method may block until command completes; optionally one bulk delivery at the end depending on flush/close behavior.

4. Run the equivalent Python get_session_command_logs_async with the same command: callbacks fire incrementally.

Expected behavior
Incremental delivery of log chunks to onStdout / onStderr while the command runs, consistent with Python, or documented contract that this WebSocket channel is always demux-framed and toolbox must emit markers—with Java and Python behaving the same.