[AX] authsome login --json omits actionable session details for interactive login flows

[ankitranjan7]

Summary

authsome login --json returns a minimal payload when a login flow requires out-of-band user interaction. That works for humans reading terminal output, but it makes the command much harder to use from agents and other programmatic clients.

The CLI already receives session metadata from the runtime, including the session ID and the next action URL, but the JSON response drops that information and only returns high-level status fields.

Because authsome is intended to be used by agents to manage credentials, interactive login flows need to expose their continuation data in a machine-usable form. This is part of the product contract, not just a convenience improvement.

Why this matters

Automated clients cannot reliably intercept webbrowser.open(...), and they should not have to scrape terminal text to continue an auth flow. In JSON mode, they need structured access to the same actionable data a human gets in the non-JSON path.

Examples:

• OAuth / PKCE flows need a URL to present to the user or hand off to a browser-automation agent.
• Device code flows may need a session identifier and, ideally, the user code or verification URL in machine-readable form.

Current behavior

When an interactive login starts, authsome login --json returns a payload like:

{
  "status": "started",
  "provider": "github",
  "connection": "default",
  "record_status": "pending"
}

This omits the fields a client needs to continue the flow, even though the CLI already has access to:

• session_info.id
• session_info.next_action
• next_action.url for URL-driven flows

Expected behavior

In JSON mode, the CLI should include actionable session details whenever they are available.

For OAuth-style flows, a response should look like:

{
  "status": "started",
  "provider": "github",
  "connection": "default",
  "record_status": "pending",
  "session_id": "sess_...",
  "auth_url": "https://github.com/login/oauth/authorize?..."
}

For device-code flows, the JSON response should also expose device-flow data when available, such as:

• session_id
• user_code
• verification_uri
• verification_uri_complete

Scope

The CLI change in src/authsome/cli/main.py is enough to expose session_id and URL-based next actions that are already present in the session response.

Exposing user_code for device-code flows likely requires extending the server session response as well, because that value is stored in the server-side session payload but is not currently included in the public session schema.

Acceptance criteria

• authsome login --json includes session_id whenever a login session is started.
• If the next action is opening a URL, the JSON includes that URL in a stable field such as auth_url.
• If device-code metadata is available, the JSON includes it in structured fields instead of requiring terminal scraping.
• Existing non-JSON behavior remains unchanged.
• CLI tests cover interactive JSON responses for both OAuth-style and device-code flows.