Allow blank usernames, asking for one at connect time instead

Closes #21. SSH and RDP profiles previously hard-required a username
to even save the profile; that validation is dropped, and
SessionTab::requestConnectOptions() now prompts for it at connect
time when blank, reusing the existing password-prompt bar in
unmasked mode -- the same pattern already used for a blank password.

VNC's username is trickier: most VNC servers never use one (plain VNC
Authentication and no-auth don't), only the two Apple auth schemes
(security types 30/33) do, and which auth method gets used isn't known
until mid-connection, after the server's security-type list has been
negotiated -- too late for the pre-connect prompt SSH/RDP uses. Adds a
new async request/response pair to SessionBackend, usernameRequested()
signal / provideUsername() slot, mirroring the existing SSH host-key-
confirmation pattern. VncSessionBackend pauses its state machine right
before computing an Apple-auth response if no username is available --
without consuming the already-buffered prime/host-key bytes, so
resuming re-parses them identically -- emits the request, and resumes
via provideUsername(). Cancelling (or submitting blank) fails the
connection cleanly instead of sending Apple auth an empty username.

The username is kept on the tab's in-memory profile copy for its
lifetime, not written back to the saved profile, matching how
passwords are already handled.

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

docs/PROGRESS.md

@@ -157,6 +157,24 @@ Delivered:
   gets its own prompt, with an empty password allowed through (unlike
   RDP's hard requirement) since some VNC servers are no-auth and there's
   no way to know that before the server's security-type negotiation
+- Profiles can now leave the username blank for every protocol (issue
+  #21): SSH/RDP previously hard-required one at profile-save time; that
+  validation is gone, and `SessionTab` now asks for it at connect time
+  instead (reusing the existing password-prompt bar in unmasked mode),
+  same as it already does for a blank password. VNC's username is only
+  ever asked for if the server's negotiated auth method actually needs
+  one -- plain VNC Authentication and no-auth never do, only the two
+  Apple schemes (30/33) do -- which happens *mid-connection*, after the
+  backend has already picked a security type, not before connecting like
+  SSH/RDP. This needed a new async request/response pair on
+  `SessionBackend` (`usernameRequested()` / `provideUsername()`,
+  mirroring the existing SSH host-key-confirmation pattern):
+  `VncSessionBackend` pauses its state machine mid-parse (without
+  consuming the already-buffered response bytes) and emits the request,
+  resuming once `SessionTab` answers; cancelling fails the connection
+  cleanly rather than sending Apple auth a blank username. The value is
+  kept on the tab's in-memory profile copy for its lifetime, not written
+  back to the saved profile
 - Robustness fix: an unrecognized `FramebufferUpdate` rectangle encoding
   used to abort the connection generically; `kAnnouncedEncodings` is now
   the single source of truth for what `SetEncodings` announces and what