feat(consensus): interactive secret-provisioning pause for fresh node install

Add an interactive "provision secrets" pause to `consensus node install` so a **fresh** install (one that also bootstraps the cluster) can stop after the cluster is up, let the operator create the required consensus-node Secrets, and then continue — instead of hard-failing at the secret precheck.

Parent epic: #408
Depends on: #1044
Relates to: #1046 (interactive prompting)

### Background
`consensus node install` requires three Secrets per node in the target namespace (`-grpc-tls-keys`, `-gossip-keys`, `-hapi-app-keys`). For a fresh install the cluster does not exist until mid-workflow, so the Secrets *cannot* exist beforehand. Today the secret precheck simply fails (now early, right after cluster bootstrap — see the precheck reorder), and the operator must pre-create the Secrets (e.g. `task uat:consensus:secrets`) and re-run.

### Proposed design — two-phase execution
Solo-weaver runs interactive prompts in `RunE` **before** the workflow (outside the automa TUI progress renderer); prompting inside a running step would collide with the progress UI. So the clean approach splits the install into two workflow phases with a pause between them, all driven from the command:

1. **Phase 1** — bootstrap cluster + ensure the target namespace exists.
2. **Pause (interactive only)** — print the exact Secret names/namespace required, wait on an interactive confirm ("create the secrets now — e.g. `task uat:consensus:secrets` — then continue"), and re-check existence on confirm (loop or abort).
3. **Phase 2** — install solo-operator + create Orbit/config/capsule CRs.

Non-interactive (`--non-interactive` / `--force` / no-TTY) keeps today's single-workflow, fail-fast behavior — the pause is skipped and missing Secrets error out.

### Scope / impact
- Touches the shared BLL orchestration: `BaseHandler.HandleIntent` currently runs a single workflow. Supporting a mid-install pause needs either two `HandleIntent`/workflow invocations from the command or a TUI-compatible gate step. This is a meaningful change, not a quick tweak — design it so block-node and other targets are unaffected.
- Only the consensus-node fresh-install path (cluster bootstrap) needs the pause; the cluster-already-exists path can keep the current early precheck.

### Acceptance criteria
- [ ] Fresh interactive install pauses after cluster bootstrap, lists the required Secrets + namespace, and continues once they exist (re-checking on confirm).
- [ ] Aborting the pause returns a clean `RejectedOperation` error rendered by the doctor layer.
- [ ] Non-interactive / `--force` keeps single-workflow fail-fast (no pause).
- [ ] Cluster-already-exists path is unchanged (early secret precheck).
- [ ] No behavioral change to block-node or other BLL targets.

### Notes
- A lighter alternative (no refactor) considered and rejected for this ticket: just print an upfront notice of the required Secrets at command start. Captured here in case scope needs trimming.

Start with the command's RunE flow and BaseHandler.HandleIntent, then trace how fresh and existing-cluster installs perform the secret precheck and workflow execution. Verify the interactive, non-interactive, and --force paths against the listed acceptance criteria, including the required Secret names and namespace. Done means only fresh interactive installs pause and re-check before continuing, without changing other targets.

Written by the indexing model from the issue text.