Fix connect-time username prompt never reaching SSH/RDP authentication

The username entered at the connect-time prompt (added for issue #21)
was updating SessionTab's own in-memory Profile copy, but
SshSessionBackend/RdpSessionBackend are constructed with -- and only
ever read from -- their own separate Profile copy on a worker thread,
which never saw that edit. Authentication was still built from the
original (blank) username regardless of what was typed into the
prompt.

SessionConnectOptions gains a username field, populated by SessionTab
on every connect attempt and threaded through the same way password
already is; both backends now prefer options.username over
profile().username. Covered by a new SSH regression test using an
exact-match fixture host that only succeeds for a specific
user@host target.

Bump version to v2026.9.16.5.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

tests/fixtures/fake_ssh.sh

@@ -6,6 +6,22 @@
 # host, optionally as user@host, as the final argument).
 for arg in "$@"; do
     case "$arg" in
+        prompted-user@requireuser)
+            # Only the exact user@host below is accepted -- used to prove a
+            # username supplied via SessionConnectOptions (prompted for at
+            # connect time because the saved profile's own username was
+            # blank) actually reaches the ssh command line, not just that
+            # *some* connection to this host succeeds.
+            echo "Welcome to the fake host."
+            while IFS= read -r line; do
+                echo "$line"
+            done
+            exit 0
+            ;;
+        *@requireuser|requireuser)
+            echo "Permission denied (publickey,password)." >&2
+            exit 255
+            ;;
         *@succeed|succeed)
             echo "Welcome to the fake host."
             # Stay alive echoing stdin back (simulates an interactive