split triggered from one attached client can create the new pane in a different attached session/client

[WangErgouaaaa]

Summary

I am filing this as a narrower follow-up to #35 because I can reproduce a separate live-session problem:

When multiple attached clients/sessions share the same rmux daemon/socket, triggering a split from one visible client can create the new pane in a different attached session/client.

Environment

• rmux: 0.5.0
• OS: Linux x86_64
• interactive shell / terminal use
• multiple attached rmux clients sharing the same default socket/daemon

Repro shape

1. Start two top-level rmux clients/sessions that share the same daemon/socket.
3. In client A, press prefix + % (or equivalent split binding).
5. Observe where the new pane actually appears.

Actual

The split can land in the other attached session/client instead of the one where the keybinding was triggered.

In my case, I could see:

• client A still showing its original single pane
• client B suddenly gaining the new pane

So the split succeeded, but it targeted the wrong attached session.

Expected

The split should always affect the client/session where the keybinding was triggered.

Notes

I do have a local workaround: I stopped sharing one default rmux socket across multiple top-level interactive clients and instead used one rmux socket per outer terminal.

That avoids the problem locally, but it still feels like the live split path is resolving the wrong attached-client context when multiple clients share one daemon.

If you prefer, I am also happy to collapse this back into #35, but I wanted to separate:

• wrong cwd with -c "#{pane_current_path}"
• wrong attached session/client targeting

because they seem related but not identical.