conn_sock.c audit

If someone were _very_ bored… `conn_sock.c` could use an overhaul.
- There are basically 5 distinct kinds of file descriptors (console/notify source, stream/notify destination, listener), modeled as 2 structs + enums.
- The code assumes, but does not structurally promise — or even _document_ — that console/stream goes together (look at the opt_stdin special case)
- AFAICS `remote_sock_shutdown` can close a file descriptor while a `remote_sock_cb` is still pending
- ` if (num_read < 0) return G_SOURCE_CONTINUE;` looks suspicious

I’m not at all saying any of these things matter in production.

I also rather strongly suspect that refactoring this with _confidence_ requires tooling support. I.e. it is… both dependent on, and a prerequisite of :), moving to something like Rust.

Start by reading conn_sock.c and mapping the five file-descriptor roles, the two structs, and their enums. Review the opt_stdin special case, remote_sock_shutdown versus pending remote_sock_cb callbacks, and the num_read < 0 condition. Done means the audit findings have been verified and an agreed refactoring scope is documented; the issue also notes possible tooling and Rust dependencies.

Written by the indexing model from the issue text.