[client/ui-wails] Make the SSO login flow recoverable from a stuck state

A pending WaitSSOLogin parks the daemon on an OAuth UserCode forever
once the user closes the browser without completing the flow. The
frontend can't unblock that on its own — it needs the daemon to fire
its own actCancel(). Three fixes work together:

- Login() now issues a Down() before kicking off the new flow so a
  previously-stuck WaitSSOLogin is unwedged before we ask the daemon
  for fresh OAuth info.
- The Login page's Cancel button calls Down() before navigating away,
  so abandoning the flow mid-browser actually settles the daemon's
  in-flight WaitSSOLogin instead of leaving it pinned.
- Status keeps the Login button visible whenever we aren't Connected
  (including Connecting), so a UI restart that finds the daemon stuck
  in Connecting still has a one-click recovery path.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

client/ui-wails/services/connection.go

@@ -65,6 +65,17 @@ func (s *Connection) Login(ctx context.Context, p LoginParams) (LoginResult, err
 		return LoginResult{}, err
 	}
 
+	// Reset the daemon's connection loop before kicking off a new login.
+	// If a previous Login left a WaitSSOLogin pending (user closed the
+	// browser without completing the flow), the daemon stays parked on the
+	// old UserCode and replies with "invalid setup-key or no sso information
+	// provided" to a fresh Login. Calling Down first dislodges that state;
+	// we ignore the error since Down on an already-idle daemon is a no-op.
+	if _, derr := cli.Down(ctx, &proto.DownRequest{}); derr != nil {
+		// Down failed — likely because the daemon is already idle. Continue.
+		_ = derr
+	}
+
 	// Mirror the Fyne client's defaulting: when the frontend doesn't supply
 	// profile / username, fall back to the daemon's active profile and the
 	// current OS user. The flag matches the Fyne ui's IsUnixDesktopClient