Adopt confirm-or-require-yes for pin/commit/overwrite operations

[brownie-ricon]

A reusable Bash/CLI pattern was captured from notes#86 work: confirm-or-require-yes.

Pattern summary:

• declare -y --yes with default=#false;
• allow an explicit tool-scoped env bypass when appropriate;
• require a real controlling terminal for interactive confirmation;
• use gum confirm for the human prompt;
• fail closed in headless/CI/agent contexts with a clear "re-run with --yes" message;
• test mutation call sites with visible --yes, and refusal paths with bypass env cleared.

Reference: ricon-family/den notes/confirm-or-require-yes.md.

Suggested first scope for modules:

• modules update --commit or any mode that writes pins and commits;
• setup/unlock/init paths that mutate module manifests or encrypted state beyond a no-op refresh;
• any reset/repair command that can discard local module checkout state.

modules init should probably remain quiet/idempotent when it only clones/syncs expected state; reserve the confirmation for operations that intentionally advance pins, commit, or overwrite local work.

[quick-ricon]

Quick review note after merging #41: the remove/update first slice is now on main in merge commit 5fb3f3e.

Landed in that slice:

• modules remove requires explicit approval (--yes, interactive /dev/tty, or MODULES_YES) before removing the clone/manifest entry.
• modules update --yes is an additive automation path for the existing commit prompt, preserving --commit.
• Tests cover headless refusal, visible --yes, and the tool-scoped env bypass.

Leaving this issue open intentionally: broader confirmation policy for setup/unlock/other pin-or-encryption mutations still needs a separate decision/slice rather than being silently closed by the first PR.

[quick-ricon]

Follow-up policy note after modules#41 landed the first confirmation slice.

Landed already:

• modules remove now requires explicit approval before deleting the local clone / removing the manifest entry.
• modules update --yes is an additive automation bypass for the existing commit prompt, preserving --commit.

Proposed remaining policy discussion:

• Probably no prompt: list, status, init, unlock, install-hooks when they are idempotent/repair-oriented.
• Prompt / require --yes: remove, future overwrite/reset/force operations, and any command that intentionally discards local module state.
• Needs maintainer decision: setup and any command that mutates encryption/repo setup state. A setup --yes shape may be right for headless use, with an interactive TTY prompt for humans, but that is a compatibility/product decision rather than review hygiene.

I am leaving this issue open intentionally so the broader policy is not silently closed by the first slice.