[AX] Add wait and polling primitives for asynchronous login sessions

[ankitranjan7]

Summary

authsome login currently starts an auth session and returns before many interactive flows are actually complete. That is visible in both the user-facing output and the tests:

• the CLI starts a daemon auth session
• opens the browser or directs the user to continue elsewhere
• prints that login has started and should be verified later
• exits with code 0

That behavior is workable for a human in a terminal, but it is awkward for agents. Because authsome is intended to be used by agents to manage credentials, the CLI needs a first-class way to wait for or poll login completion instead of treating "session started" as the end of the workflow.

Current behavior

Today, login behaves like an asynchronous session starter:

• if the daemon reports completed immediately, the CLI returns success
• otherwise the CLI reports a started/pending state and exits
• non-JSON output tells the user to run authsome list later to verify completion
• JSON output currently returns a started status for pending flows

Relevant facts in the current codebase:

• src/authsome/cli/main.py prints Login started ... Run 'authsome list' to verify completion. for pending flows
• src/authsome/cli/client.py already has a get_session(session_id) method for the daemon's GET /auth/sessions/{session_id} API
• there is no standalone CLI command for checking auth session status
• there is no --wait mode on authsome login

There is also a documentation mismatch today: the daemon API reference says the CLI starts a session, opens a browser, waits for completion, and finalizes the connection, but the current CLI implementation does not wait.

Why this matters

For agents and automation, "session started" and "credential established" are different states.

Without a first-class wait or polling primitive, callers have to choose between poor options:

• assume exit code 0 means usable credentials, which is wrong for pending flows
• scrape human text like Run 'authsome list' to verify completion
• poll unrelated commands like authsome list
• bypass the CLI and talk to the daemon API directly

For an agent-oriented credential CLI, login completion needs a machine-usable surface.

Proposed behavior

Add two related CLI capabilities:

1. authsome login --wait

• start the login session as today
• if the session is already completed, return immediately
• otherwise poll the auth session until it becomes completed or failed
• exit 0 only when the credential is actually ready for use
• exit non-zero on failure or timeout

2. authsome session status <session_id>

• expose the existing daemon session-status API as a machine-friendly CLI command
• support --json like the rest of the CLI
• return session state such as pending, waiting_for_user, completed, or failed together with any available message/error fields

Relationship to #320

This is related to #320, but not the same issue.

• #320 is about including actionable session details like session_id and auth_url in the initial login --json response
• this issue is about what callers can do after the session starts: wait for completion or poll its status through the CLI

A stable session_id in JSON is an important prerequisite for the polling workflow, but the waiting/polling surface is a separate capability gap.

Scope

Likely touch points:

• src/authsome/cli/main.py (login command)
• src/authsome/cli/client.py (get_session is already available)
• new CLI command group or subcommand for session inspection
• docs for login semantics and session polling

Acceptance criteria

• authsome login --wait exists and waits for session completion.
• In --wait mode, the command exits 0 only when the credential is actually established.
• In --wait mode, failures and timeouts exit non-zero and use structured JSON errors when --json is enabled.
• authsome session status <session_id> exists and exposes the daemon auth-session state through the CLI.
• The command supports --json and returns machine-usable session state.
• Login/session docs accurately describe the actual behavior of the CLI.

[manojbajaj95]

No need for this. It add complexity that is not needed.