BUG: creating a session with slash in its name is broken

[skissane-medallia]

AI Policy Ack
ACK

What happened
If you start your session name with a /, e.g. shpool attach /, the shpool attach command will hang.
shpool list will show the session exists disconnected, but any attempt to attach to it fails

What I expected to happen
Either fail with an error (/ is not a valid character in a session name) or work

To Reproduce
Steps to reproduce the behavior:
shpool attach /

Version info
shpool 0.9.8

Logs

2026-05-06T01:48:33.633855Z  INFO ThreadId(01) run:serve: socket got a new connection
2026-05-06T01:48:33.633971Z  INFO ThreadId(01) run:serve: socket got a new connection
2026-05-06T01:48:33.634100Z  INFO ThreadId(49) handle_conn{cid=27}: new
2026-05-06T01:48:33.634135Z  INFO ThreadId(49) handle_conn{cid=27}:parse_connect_header: new
2026-05-06T01:48:33.634092Z  INFO ThreadId(48) handle_conn{cid=26}: new
2026-05-06T01:48:33.634181Z  INFO ThreadId(48) handle_conn{cid=26}: broken pipe while writing version, likely just a daemon presence probe
2026-05-06T01:48:33.634188Z  INFO ThreadId(48) handle_conn{cid=26}: close time.busy=13.2µs time.idle=84.0µs
2026-05-06T01:48:33.634288Z  INFO ThreadId(49) handle_conn{cid=27}:parse_connect_header: close time.busy=148µs time.idle=4.08µs
2026-05-06T01:48:33.634338Z  INFO ThreadId(49) handle_conn{cid=27}:handle_attach: new
2026-05-06T01:48:33.634397Z  INFO ThreadId(49) handle_conn{cid=27}:handle_attach:build_shell_env: new
2026-05-06T01:48:33.634407Z  INFO ThreadId(49) handle_conn{cid=27}:handle_attach:build_shell_env: injecting TERM into shell Some("xterm-256color")
2026-05-06T01:48:33.634431Z  INFO ThreadId(49) handle_conn{cid=27}:handle_attach:build_shell_env: close time.busy=30.3µs time.idle=3.49µs
2026-05-06T01:48:33.634435Z  INFO ThreadId(49) handle_conn{cid=27}:handle_attach:select_shell_lock_1(shells): new
2026-05-06T01:48:33.634438Z  INFO ThreadId(49) handle_conn{cid=27}:handle_attach:select_shell_lock_1(shells): found entry for '/'
2026-05-06T01:48:33.634441Z  INFO ThreadId(49) handle_conn{cid=27}:handle_attach:select_shell_lock_1(shells):aquired_lock(session.inner){s="/"}: new
2026-05-06T01:48:33.634444Z  INFO ThreadId(49) handle_conn{cid=27}:handle_attach:select_shell_lock_1(shells):aquired_lock(session.inner){s="/"}: taking over existing session inner
2026-05-06T01:48:33.634458Z  INFO ThreadId(49) handle_conn{cid=27}:handle_attach:select_shell_lock_1(shells):aquired_lock(session.inner){s="/"}: close time.busy=14.9µs time.idle=2.48µs
2026-05-06T01:48:33.634464Z  INFO ThreadId(49) handle_conn{cid=27}:handle_attach:select_shell_lock_1(shells): close time.busy=26.5µs time.idle=2.25µs
2026-05-06T01:48:33.634467Z  INFO ThreadId(49) handle_conn{cid=27}:handle_attach:select_shell_lock_3(shells): new
2026-05-06T01:48:33.634469Z  INFO ThreadId(49) handle_conn{cid=27}:handle_attach:select_shell_lock_3(shells): close time.busy=374ns time.idle=2.12µs
2026-05-06T01:48:33.634473Z  INFO ThreadId(49) handle_conn{cid=27}:handle_attach:link_ssh_auth_sock: new
2026-05-06T01:48:33.634477Z  INFO ThreadId(49) handle_conn{cid=27}:handle_attach:link_ssh_auth_sock: close time.busy=2.10µs time.idle=2.23µs
2026-05-06T01:48:33.634482Z  INFO ThreadId(49) handle_conn{cid=27}:handle_attach: close time.busy=141µs time.idle=3.11µs
2026-05-06T01:48:33.634485Z  INFO ThreadId(49) handle_conn{cid=27}: close time.busy=370µs time.idle=16.8µs
2026-05-06T01:48:33.634488Z ERROR ThreadId(49) handling new connection: linking SSH_AUTH_SOCK

Caused by:
    no sessions dir

[skissane-medallia]

I think the obvious fix is to ban / from session names. Having / in session name causes problems attempting to use the session name in paths, e.g. the /run/shpool/$UID/$HEX/sessions/$SESSION_NAME directory. shpool attach should fail with an error in that case.

For the same reason, the session names . and .. should be banned. Unlike / they appear to actually work (at least sometimes), but are likely putting things in an unexpected directory. Maybe ban initial . altogether?

The alternative would be to make sure the session name is encoded (e.g. URI encoding) before using it in filesystem paths. But that's probably overcomplicating it, it is easier just to disallow these characters.