fix(wizard): pass --default=no so default_no prompts actually preselect No

[royosherove]

The bug

confirm() and toggle() in install.sh passed an explicit flag only on their
affirmative branch. The negative branch called gum confirm bare:

if [[ "$default" == "default_yes" ]]; then
  $GUM confirm --default=yes "$text" < /dev/tty || rc=$?
else
  $GUM confirm "$text" < /dev/tty || rc=$?   # <-- no --default
fi

gum's --default is a bool declared default:"true" in
confirm/options.go,
and confirm/command.go
seeds the TUI with choice := o.Default. Omitting the flag therefore preselects
Yes.

Net effect: every default_no prompt rendered with Yes highlighted — the
opposite of its stated default — so a user pressing Enter opted in to a
feature the code intended to default off.

Affected prompts

Line	Prompt	Declared	Actually rendered
2150	Protect <pack> WebUI with Cognito login? (enterprise-grade)	default_no	Yes
3411	Connect KiroCrew to Telegram? (chat with your agent from your phone)	default_no	Yes

toggle() carried the same inversion for any caller passing a false default.

The fix

Both helpers now pass --default=no explicitly, so neither branch depends on
gum's implicit value. Four $GUM confirm call sites exist and all four now
name their default.

Verification

• bash -n install.sh and bash -n uninstall.sh: OK
• shellcheck --severity=error install.sh uninstall.sh: 0 findings
• grep '$GUM confirm' install.sh | grep -v -- '--default=' → empty, so no call
  site relies on the implicit default

Behaviour was confirmed from gum v0.14.5's source rather than from exit codes:
gum confirm returns the negative for every flag combination when it has no
TTY, so a non-interactive exit-code probe cannot distinguish the cases and is
not valid evidence here.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 38d4e02feb

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Use false for Gum’s boolean default flag

With Gum v0.14.5, --default is a boolean whose explicit value is decoded through Kong’s strconv.ParseBool mapper; the Go documentation lists accepted false values as 0, f, and false, not no. Consequently --default=no is rejected before the TUI opens, and the surrounding || rc=$? silently converts that parse failure into a negative answer. During interactive installs, every default-no prompt—including Cognito, Telegram, AWS CLI updates, quota requests, and some continue/abort paths—therefore becomes impossible to accept; pass --default=false instead.

Useful? React with 👍 / 👎.

[royosherove]

Thanks — but this is a false positive, and gum's own error message is the disproof.

Gum does not use Kong's stock strconv.ParseBool mapper for this flag; it registers a custom bool mapper. Feeding it a value that mapper rejects makes it enumerate exactly what it accepts:

$ gum confirm --default=f q
gum: error: --default: bool value must be true, 1, yes, false, 0 or no but got "f"

So the accepted set is true, 1, yes, false, 0, no — yes and no are valid, while t and f are the values that get rejected. That is the inverse of what strconv.ParseBool would do, which is what makes the ParseBool premise identifiable as the wrong model here.

Probed across the full range on gum v0.14.5 (linux/arm64), capturing stderr:

value	parse error?
no	none
false	none
0	none
yes	none
true	none
1	none
f	rejected
t	rejected

Two further points against the finding as written:

1. If yes/no were rejected, the pre-existing --default=yes on the affirmative branch — untouched by this PR and shipping for many releases — would have been silently broken the whole time, turning every default_yes prompt negative. That has not been observed.
2. The claimed symptom is that default-no prompts become "impossible to accept". Under the actual mapper there is no parse failure, so rc reflects the user's real choice.

--default=false would also work and is equivalent; I'm keeping no because it reads symmetrically against the existing --default=yes on the adjacent branch. No code change.

Note the exit code alone cannot settle this: gum confirm returns 1 for every flag combination when it has no TTY, so a non-interactive exit-code probe is not valid evidence. The parse error on stderr is, because argument parsing happens before the TUI opens.