chore(configure): surface reader.ReadString errors in remaining wizard prompts #1283

Context

golangci-lint (with errcheck.check-blank: true) flags every _, _ := reader.ReadString('\n') / _, _ := f() site in the configure wizards. Most of these sites pre-date PR #1279, which only patched the four sites it introduced (commit a526f1a). The Lint Code job stays failing on main because of the remaining sites — they need a sweep.

Memory entries that this touches:

• feedback_no_silent_fallbacks.md — return an explicit error rather than discarding it.

Pre-existing sites (file:line:column at PR #1279 HEAD a526f1a)

cmd/configure_azure.go

• 380:18 — azureStepListSubscriptions: subscriptionID, _ := reader.ReadString('\n')
• 493:10 — promptAndRunExplicitCommand: choice, _ := reader.ReadString('\n')
• 529:13 — executeExplicitCommand: response, _ := reader.ReadString('\n')

cmd/configure_gcp.go

• 186:14 — getGCPCredentialsFilePath: credsFile, _ = reader.ReadString('\n')
• 563:13 — gcpStepSelectProject: projectID, _ := reader.ReadString('\n')
• 701:10 — promptAndRunGCPCommand: choice, _ := reader.ReadString('\n')
• 736:13 — executeGCPCommand: response, _ := reader.ReadString('\n')

(All seven existed on main before PR #1279; same shape, only the line numbers shifted with that PR.)

Acceptance

• All seven reader.ReadString sites surface the error per the same pattern PR refactor(configure): replace az/gcloud CLI shell-outs with native SDK calls #1279 already used for its four sites: choice, err := reader.ReadString('\n'); if err != nil { return ..., fmt.Errorf("failed to read ...: %w", err) }.
• golangci-lint run ./cmd/... passes (or at least the errcheck lines for these files drop to zero).
• Existing wizard tests still pass; no behaviour change beyond "interactive flow fails loud on closed stdin instead of running the default action".

Out of scope

• The broader errcheck sweep across internal/api/*, internal/auth/*, internal/mocks/* etc. that the same lint run reports — those are independent of the configure wizards and should be tracked in a separate sweep issue if not already.