gws auth login --help (and -h) is silently ignored — starts the OAuth flow instead of printing help

[lgameplayer]

Summary

gws auth <method> --help (and -h) is silently ignored — the help flag does not print help, and the subcommand executes
its real action instead. This is at minimum surprising and at worst dangerous for auth login, which triggers an OAuth
flow (printing an authorization URL and waiting on stdin) when the user only intended to read the help text.

Other gws commands handle --help correctly, which makes the inconsistency the most notable part.

Reproduction

Tested on @googleworkspace/cli 0.18.1, macOS 26.4.1, Node 24.14.0.

$ gws auth login --help                                        
Open this URL in your browser to authenticate:
  https://accounts.google.com/o/oauth2/auth?scope=...&redirect_uri=http://localhost:52908&...
# → starts a real OAuth flow, binds a localhost redirect port, waits on stdin                                              

$ gws auth login -h                                                                                                        
# same — starts the OAuth flow                                                                                             

$ gws auth setup --help                                                                                                    
Step 1/6: Checking for gcloud CLI...                           
  ✓ gcloud CLI found
# → starts the real interactive setup wizard
                                                                                                                           
$ gws auth status --help
Using keyring backend: keyring                                                                                             
# → runs the status command                                    

For comparison, these work correctly:

$ gws --help
gws — Google Workspace CLI                                                                                                 
USAGE: ...                                                     
# ✓ prints help

$ gws auth                              # no subcommand
Usage: gws auth <login|setup|status|export|logout> [options]
# ✓ prints help (this is what `--help` should produce too)                                                                 

$ gws gmail +triage --help                                                                                                 
[Helper] Show unread inbox summary (sender, subject, date)     
Usage: gws +triage [OPTIONS]                                                                                               
Options: ...
# ✓ prints help                                                                                                            

So --help is honored at the top level (gws --help), at the bare-subcommand level (gws auth), and on helper commands
(gws +triage --help) — but not on any of auth login, auth setup, auth status, auth export, auth logout. The
argument parser appears to be skipped or short-circuited for the auth methods specifically.

Why this matters

• gws auth login --help is a natural thing for a user to type while exploring the CLI. Today it has the side effect of
  starting an OAuth flow that binds a localhost port, opens a browser tab in some configurations, and may overwrite saved
  credentials when completed. That's a footgun.
• gws auth setup --help similarly starts the real interactive setup wizard, including gcloud probing. A user trying to
  learn what flags setup accepts ends up walking through actual setup.
• The inconsistency with the rest of the CLI (--help works everywhere else) is a usability bug regardless of the side
  effects.

Suggested fix

Have gws auth <method> route through the same argument parser the other subcommands use, so --help/-h short-circuits
before any side effect. The output of gws auth (the bare subcommand) is already a good template for what gws auth login --help should print.

Environment

• @googleworkspace/cli 0.18.1
• macOS 26.4.1 (Darwin 25.4.0), Node 24.14.0