[AX] Fail fast on confirmation prompts in unattended CLI usage

[ankitranjan7]

Summary

authsome still has a small number of interactive confirmation prompts intended for human terminal use. Today, unattended callers can avoid them with register --yes / --force, scan --import, or JSON mode, but if those flags are omitted the behavior depends on the execution environment.

• In some environments, Click may wait for input from an attached TTY.
• In others, such as closed or EOF stdin, Click aborts immediately.

That variability is awkward for agents and scripts. Because authsome is intended to be used by agents to manage credentials, deterministic non-interactive behavior is part of the CLI contract, not an optional automation nicety.

Current behavior

There are currently two CLI confirmation sites:

• scan uses click.confirm(...) in src/authsome/cli/helpers.py when:
  • --import is not passed
  • at least one API-key candidate is found
  • --json is not enabled
  • --quiet is not enabled
• register uses click.confirm(...) in src/authsome/cli/main.py when:
  • neither --yes nor --force is passed
  • --json is not enabled
  • --quiet is not enabled

Important constraints that already exist today:

• scan --json already skips the confirmation and returns a report-only response unless --import is provided.
• register --json already skips the confirmation prompt.
• There are no click.prompt(...) call sites in the CLI right now; the immediate scope is these two click.confirm(...) usages.

Why this matters

Agents and scripts should not need to guess whether a command will prompt, block on a TTY, or abort on EOF. For an agent-first credential CLI, a dedicated non-interactive mode would make automation behavior explicit and consistent.

Proposed behavior

Add an explicit non-interactive mode, for example via:

• a global --non-interactive flag
• an environment variable such as AUTHSOME_NON_INTERACTIVE=1

When active, any confirmation request should raise a dedicated exception instead of attempting interactive I/O.

In JSON mode, the existing error wrapper should return a structured payload such as:

{
  "error": "InteractivePromptBlocked",
  "message": "Command requires confirmation. Use --yes, --force, or --import to proceed."
}

Interactive behavior for human users should remain unchanged when non-interactive mode is not enabled.

Scope

• src/authsome/cli/helpers.py (_scan_resolve_should_import)
• src/authsome/cli/main.py (register)
• optionally a shared helper or CLI context utility for "confirmation allowed?" checks

This issue is about confirmation prompts in CLI commands. Broader interactive input paths can be handled separately if needed.

Acceptance criteria

• An explicit non-interactive mode exists via a flag, an environment variable, or both.
• scan fails fast in non-interactive mode when import confirmation would otherwise be required.
• register fails fast in non-interactive mode when confirmation would otherwise be required.
• JSON mode returns a structured error payload when a confirmation is blocked.
• Existing interactive behavior remains unchanged when non-interactive mode is off.
• Tests cover both commands in interactive and non-interactive paths.