spec: interactive wizard for context create, product add and login

Problem Statement

Setting up a context takes flags only. wso2 context create has thirteen flags and two mutually exclusive forms, and asks nothing. wso2 context product add asks nothing either. wso2 login already asks which context to use and offers to create one (#186), but its new-context branch only asks for an issuer and a client ID. The context it writes reaches no product, so a person can log in and still be unable to run a product command.

Solution

When a question can be asked (the existing mayPrompt rule: no --no-input, no WSO2_NO_INPUT, standard input is a terminal), these commands walk the user through what's missing:

• wso2 context create with no form flags runs a wizard: deployment (WSO2 Cloud listed and refused as coming soon, or your own deployment), login through an installed login product and its URL or through an OpenID issuer and client ID, provider when the descriptor can't tell, sign-in mode (browser, device code, client credentials), further products and their gateways, the name, then a summary, confirmation, an offer to select the context, and an offer to log in.
• wso2 context product add with no --url asks for the product, its URL and its gateway, shows the existing plan, and confirms before writing.
• wso2 login's new-context branch hands off to the same wizard.

Flags keep working exactly as today. With --no-input, WSO2_NO_INPUT or no terminal, nothing is asked and the current refusals name the missing flags.

The prompts use charmbracelet/huh: a TUI when standard error is a terminal, and huh's accessible mode (plain line prompts rendered from the same form) otherwise. Prompts always go to standard error.

User Stories

1. As a new user, I want wso2 context create with no flags to ask me what it needs, so that I don't have to learn two flag forms first.
2. As a new user, I want to pick my deployment from a list, so that I know WSO2 Cloud is coming and my own deployment works now.
3. As a user who picks WSO2 Cloud, I want to be told it is coming soon and to be asked again, so that the wizard doesn't end.
4. As an on-prem user, I want to pick the login product from the installed products that can be login providers, so that I don't guess a namespace.
5. As an on-prem user with no login product installed, I want to be told how to install one or to choose the issuer path, so that I'm not stuck.
6. As an on-prem user, I want the product URL checked as I type it, so that a typo costs me one line and not the whole command.
7. As an identity-product user, I want to be asked whether it's Identity Server or Thunder only when the descriptor can't tell, so that I'm asked nothing it already knows.
8. As a user without a product module for my identity provider, I want to enter an issuer URL and client ID, so that I can still log in.
9. As a Thunder user on the issuer path, I want to be told Thunder needs the identity product, so that I don't write a context that can't log in.
10. As a user on a headless machine, I want to choose device-code sign-in, so that the context logs in without a browser.
11. As a CI author, I want to choose client credentials and give the secret's environment variable name, so that no secret is typed or stored.
12. As a user, I want to add the other products the context reaches in the same wizard, so that one command leaves me ready to work.
13. As an API product user, I want to be asked for the gateway URL only when the product has a gateway, so that I'm not asked about things that don't exist.
14. As a user, I want a context name suggested and re-asked when mine is invalid or taken, so that naming never fails the command.
15. As a user, I want a summary before anything is written, so that I can check it.
16. As a user, I want to be offered to select the new context and to log in, so that the next step happens without another command.
17. As a user who presses Ctrl+C, I want to be told nothing was created, so that I know no half-written context exists.
18. As a user of wso2 context product add with no --url, I want to pick the product and enter its URL, so that I don't need to read the help first.
19. As a user replacing a product, I want to see the sessions that will end before I confirm, so that I'm not logged out by surprise.
20. As a user running wso2 login with no contexts, I want to get the same wizard as context create, so that my first login reaches products too.
21. As a user whose context reaches no product, I want login to name wso2 context product add, so that I know what to do next.
22. As a script author, I want --no-input to ask nothing and fail with the missing flags named, so that jobs never hang.
23. As a script author, I want WSO2_NO_INPUT to do the same, so that I can set it once for a whole pipeline.
24. As a script author piping standard input, I want no question to be asked, so that my input isn't consumed by a prompt.
25. As a user of --output json, I want prompts to stay on standard error, so that standard output is still valid JSON.
26. As a screen-reader user, I want plain line prompts when the TUI isn't available, so that I can still complete the wizard.
27. As an existing user, I want every flag form to behave exactly as before, so that my scripts don't change.

Implementation Decisions

• A new wizard package owns the huh dependency and exposes a small set of question kinds: select (with options that are listed but refused with a note), text input with a validation function, and confirm. It takes its reader and writer from the caller. It renders as a TUI when the writer is a terminal and in accessible mode otherwise. It never writes to standard output.
• The shell keeps deciding whether to ask through mayPrompt, unchanged. The wizard package decides only how to ask.
• Answers are turned into the same flag structures the commands already parse and go through the same validation and descriptor resolution (checkContextCreateFlags, resolveLoginProduct, the product-add plan). The wizard writes nothing itself, so frozen defaults (ADR 0016) behave exactly as for typed flags.
• context create runs the wizard only when it's given neither --login-product nor --issuer and a prompt is allowed. The name argument becomes optional in that case. When a prompt isn't allowed, the existing refusals apply.
• The login-product choices are the installed products whose descriptor names a provider.
• context product add runs its wizard when --url is missing and a prompt is allowed. Otherwise it refuses as today.
• wso2 login's new-context branch calls the create wizard and then logs in to the result. Cloud stays a refused option with the existing wording.
• The existing numbered prompts (login target, context name, client ID, context edit's "edit again", module confirmations) move to the wizard package, so a journey uses one prompt style.
• A cancelled wizard (huh's user-abort) is reported as shell.cancelled, usage class (exit 64), with "Nothing was written."
• Adding huh is recorded in ADR 0017, and a boundaries test keeps the dependency inside the wizard package.

Testing Decisions

• Tests exercise commands through Shell.Run with a scripted Shell.Reader, and assert prompts on standard error, results on standard output, the exit class, and the written context document. They don't assert on internal helpers.
• In tests the wizard renders in accessible mode (buffers aren't terminals), so the scripted answers are plain lines.
• failIfReadReader proves --no-input, WSO2_NO_INPUT and non-terminal paths never reach a question.
• Prior art: login_target_test.go, login_create_test.go, context_test.go, and the acceptance login tests.
• Wizard package unit tests cover each question kind, re-asking on invalid input, refused options, and abort.

Out of Scope

• The real WSO2 Cloud login (it needs the WSO2-published public client).
• Wizards for context use, delete, apply, edit, and doctor repair.
• Asking for organization, project, audience or scopes. These stay flags.

Further Notes

Builds on #186 and the context v4 work on feat/context-v4.

Start with the context create, context product add, and login command entry points, then read login_target_test.go, login_create_test.go, context_test.go, and the acceptance login tests. Trace how Shell.Run supplies scripted input and how prompts and results are asserted. Done means the wizard covers the stated interactive and non-interactive paths, preserves flag behavior, and writes only after confirmation.