fix: onboarding defects (Ctrl-C data corruption, false secret-scan warning, traceback leaks) + openai-chatgpt first-class + login wizard

[Brian Krabach (bkrabach)]

The owner's broken onboarding transcript

$ amplifier provider add openai-chatgpt
...model fetch...
Traceback (most recent call last):
  ...
amplifier_module_provider_openai_chatgpt.AuthenticationError: ...
  (raw traceback dumped to terminal)
...falls back to a stale/empty model list...
Choice [1/2/3]: ^C
✓ OpenAI ChatGPT configured
⚠ Could not resolve provider module '...' for entry '...' -- skipping plaintext-secret scan for this entry.

Four distinct defects, all hit in one provider add openai-chatgpt run, plus
provider-openai-chatgpt was never actually registered as a well-known
provider. This PR fixes all four, registers the provider, and adds the
onboarding improvement (wizard login step) the transcript was missing.

Fix 1 (highest severity, data-corrupting): Ctrl-C during model selection silently "succeeded"

Root cause: _prompt_model_selection() already returns None on
KeyboardInterrupt/EOFError (provider_config_utils.py:187-188, documented at
:93-94). Its caller inside configure_provider() only checked
if selected_model: -- a falsy check that treats the strict abort sentinel
(None) the same as "" (user declined to type a custom model name, a valid
continue-without-a-model outcome). An interrupted model prompt fell straight
through to Phase 3, printed "✓ ... configured", and returned a config dict
instead of None.

Fix: disambiguate at the call site: selected_model is None now aborts
configure_provider() immediately with the same "Cancelled." message the
outer except (KeyboardInterrupt, EOFError) handler already prints
(:984-986), matching the precedent in commands/routing.py's model picker
(if selected is None: return None). "" still falls through to
"no model set, continue" unchanged.

This single fix (inside configure_provider() itself) lands the abort on
all three call sites that already correctly check if config is None: ...
after calling it: provider add (commands/provider.py:607), the
manage-loop's add flow (:1403), and provider edit (:951) -- the last of
which was silently overwriting a working default_model with a config
that had none.

Fix 2: false "Could not resolve provider module" warning

Root cause: normalize_provider_secrets() printed a loud yellow warning
whenever _secret_field_id_for(module_id) returned None -- but that's the
return value for TWO different situations: a genuine resolution failure, and
(equally) a provider that resolves fine but simply declares no
field_type == "secret" ConfigField at all -- the normal shape for any
OAuth-based provider (openai-chatgpt, github-copilot, ...).

Fix: call get_provider_info(module_id) once per entry and branch on it
directly. None keeps the loud warning (genuine failure). A resolved info
with no secret field now only logs at debug level. Added
_secret_config_field_from_info()/_secret_field_id_for_info() so the
already-fetched info dict is reused instead of a second get_provider_info()
call.

Fix 3: the traceback-leak class (kills it for ALL providers, not just this one)

Root cause: amplifier-app-cli configures no logging anywhere --
verified zero basicConfig()/dictConfig()/addHandler() calls in the
codebase. With no root handlers, Python's logging.lastResort dumps bare
messages and full tracebacks from any module's
logger.warning(..., exc_info=True) straight to stderr. This is exactly how
the raw AuthenticationError leaked during the model fetch above -- and it
would leak the same way for any provider, any logged exception.

This also explains why _attach_llm_error_filter() (main.py:185-204) was
inert: its primary path attaches to an existing stderr StreamHandler, but
with none configured it always fell back to root.addFilter(...) -- a
logger-level filter, which Logger.callHandlers() never consults for
records emitted by a child logger (it only checks the originating
logger's own filters, not the root's, while walking handlers up the
hierarchy).

Fix: added _configure_console_logging(), called from main() before
_attach_llm_error_filter(). If root has no handlers, installs one stderr
StreamHandler at WARNING with a plain "%(message)s" formatter, and --
unless --verbose/-v/--debug is on the command line -- a filter that
clears exc_info/exc_text so a logged exception still prints its message
but never dumps a raw traceback. This also makes _attach_llm_error_filter()'s
primary (correct) path fire for the first time.

Fix 4: provider-openai-chatgpt was never a well-known/first-class provider

git log -p -- amplifier_app_cli/provider_sources.py and
git log --all --oneline | grep -i chatgpt (searched at f9a2e15, and
re-verified on this branch): no commit anywhere in history ever added it to
DEFAULT_PROVIDER_SOURCES. Added it there (alphabetically) and
"openai-chatgpt" -> "OpenAI ChatGPT" to _PROVIDER_DISPLAY_NAMES.
Deliberately no PROVIDER_DEPENDENCIES entry -- the module is standalone
(verified), unlike e.g. azure-openai extending openai.

The onboarding improvement: wizard login step + provider login

For a provider that declares an "auth:*" capability in get_info()
(e.g. "auth:oauth-device-code"), configure_provider() now offers a
one-time browser login before fetching models, so a first-time user
gets the live model catalog instead of the stale/empty fallback list the
transcript above hit. Decline or failure prints one graceful yellow line
and continues (never a traceback); Ctrl-C aborts cleanly via fix 1's
mechanism. Also added amplifier provider login <id> to (re)authenticate
later, sharing the same login-driving helper as the wizard step.

The duck-typed auth contract (why this merges safely on its own)

A parallel provider-module PR is adding auth_status() -> "authenticated" | "expired" | "unauthenticated", async login(print_fn=None) -> bool, and an
"auth:oauth-device-code" capability in get_info() to
provider-openai-chatgpt. This PR never assumes those exist -- it checks
get_info()["capabilities"] for an "auth:"-prefixed string, then
hasattr(provider, "auth_status")/hasattr(provider, "login") before using
them. A provider that declares the capability but doesn't (yet) implement
the methods is treated exactly like one with no login flow at all (instance
still reused for model-fetch efficiency; no crash, no login prompt).
The login step activates fully once the provider PR merges -- no
follow-up change needed here.

Quality

• Fail-before/pass-after evidence for fixes 1 and 2 (stash-compared against
  this branch's own fix commits).
• Full suite: 1508 passed baseline -> 1560 passed / 0 failed after (52 net
  new regression tests, zero regressions).
• ruff format/ruff check clean on every touched file (this repo's own
  toolchain and config -- CI here runs pytest -q only, no lint job).
• One pre-existing self-audit test (test_discover_providers_clean_install .py::...test_provider_display_names_are_correct_for_all_fallbacks) is
  updated in the same commit that added the new provider, per its own
  "keep me in sync" comment.

Conventional commits, one fix/feature per commit, ordered as designed.

🤖 Generated with Amplifier

Co-Authored-By: Amplifier 240397093+microsoft-amplifier@users.noreply.github.com

[Brian Krabach (bkrabach)]

All CI checks are green (license/cla, pytest across ubuntu/macos/windows x py3.11/3.12, and the integration job). This PR is self-authored by a maintainer session and is being merged with admin privileges at the repository owner's direct instruction, per the documented maintainer admin-merge pattern (checks-green-first; never merge over a failing check). Branch review-gate (REVIEW_REQUIRED) is bypassed via --admin for this reason; branch is not deleted on merge.