feat: add --tmux-socket flag and TmuxClient socket routing

[kalbasit]

Problem

When laio is used as a tmux plugin — where tmux runs on a non-default socket — every laio command was silently targeting the default tmux server. This caused laio to operate on the wrong server or fail outright.

Solution

Add a global --tmux-socket <path> flag (and LAIO_TMUX_SOCKET env var fallback) that pins all tmux operations to the specified server. The flag lives on the top-level CLI struct so it applies consistently to every subcommand without needing to be threaded through each one manually.

• TmuxClient stores the socket and prepends -S <path> to every tmux invocation
• start, stop, list, config list, session list, and session yaml all honor the resolved socket
• The M-l picker popup binding embeds --tmux-socket in the reopened laio start --show-picker command so the picker re-opens against the same server
• Passing --tmux-socket with Zellij emits a warning and is ignored (flag is tmux-specific)

Test plan

• cargo test --quiet passes
• laio --tmux-socket /tmp/my.sock start <session> targets the correct server (tmux -S /tmp/my.sock ls confirms)
• LAIO_TMUX_SOCKET=/tmp/my.sock laio start <session> works identically
• --tmux-socket takes priority over LAIO_TMUX_SOCKET
• Pressing M-l inside a session started with --tmux-socket reopens the picker on the same server

[kalbasit]

This change is part of the following stack:

• feat: add --tmux-socket flag and TmuxClient socket routing #360 ◀

_{Change managed by git-spice.}

[kalbasit]

@ck3mp3r Thanks for Laio!

My project swm makes use of laio, and this PR (and another upcoming PR) are required to make it work. Do you mind giving this a review?

[ck3mp3r]

@kalbasit I think this use case is very specific to your workflow and changing the cli api and just adding socket support for tmux and not zellij does not feel like sound architecture. Also the implementation feels like a bolt on to be honest. I would have liked a more generic approach. Have you tried using an environment variable inside your cli to control where tmux has the socket for sessions wrapped by your cli?

[kalbasit]

@kalbasit I think this use case is very specific to your workflow and changing the cli api and just adding socket support for tmux and not zellij does not feel like sound architecture. Also the implementation feels like a bolt on to be honest. I would have liked a more generic approach. Have you tried using an environment variable inside your cli to control where tmux has the socket for sessions wrapped by your cli?

Thanks — the bolt-on critique is fair, and I think there's a cleaner path that doesn't add any CLI surface at all.

$TMUX already carries the socket path (socket,pid,session), and laio reads it via is_inside_session(). Parsing the socket out and prepending -S <socket> to tmux commands whenever $TMUX is set would replace --tmux-socket entirely — no flag, no env var, and no change to anyone's existing usage:

• User on the default socket: extracted path matches what plain tmux would resolve to → behaviour unchanged.
• User outside tmux: $TMUX unset → behaviour unchanged.
• User on a custom socket (tmux -L name / tmux -S /path): laio currently issues commands on the default socket while the user is on a different one, and switch-client can't find the session it just created. Reading from $TMUX fixes that — bug fix, not a behaviour change.

For zellij, the same pattern would apply with $ZELLIJ if/when it makes sense — separate PR.

Would dropping --tmux-socket / LAIO_TMUX_SOCKET entirely in favour of $TMUX-derived routing match what you had in mind? Happy to rework.