WS-18: fix(workstation): `reword-head` rewrites HEAD without the confirmation its sibling `amend-head` requires

[gfargo]

File: src/workstation/runtime/inkWorkflows.ts (registry entry for reword-head)

What's wrong: Enumerating the registry against HISTORY_REWRITE_WORKFLOW_IDS
(useWorkflowAction.ts:157-168) shows exactly one history-rewriting workflow with no
requiresConfirmation:

--- history-rewriting workflows WITHOUT requiresConfirmation ---
  reword-head {"kind":"normal","label":"Reword HEAD commit message"}

All 9 siblings (amend-head, reset-to-commit, cherry-pick-commit, revert-commit,
fixup-into-commit, autosquash-rebase, interactive-rebase, execute-rebase-plan,
rebase-onto-branch) gate on a y-confirm.

Impact: reword-head rewrites the HEAD commit (invalidating any push) with no confirmation
step. Consent is arguably implicit because the flow opens an input prompt for the new message, but
the asymmetry with amend-head — which also prompts and confirms — means the same class of
rewrite has two different safety levels.

Suggested fix: Either add requiresConfirmation: true for parity, or document the
"prompt implies consent" rule and drop it from amend-head too. Add a registry-invariant test
asserting every id in HISTORY_REWRITE_WORKFLOW_IDS follows the chosen rule.

Confidence: high (the asymmetry is verified; whether it is wrong is a product call)

---

---

Extracted from a repo audit performed 2026-07 (the audit doc it came from was proposed via an unmerged docs PR).

[gfargo]

Investigated this — confidence in the asymmetry is correct, but I don't think it's a bug.

reword-head's handler (useWorkflowAction.ts) opens an input prompt pre-seeded with the current commit subject; submitting that prompt is what actually fires the rewrite. There's an existing code comment on this registry entry (inkWorkflows.ts, dating to #1350) saying exactly this: "opens an input prompt seeded with the current subject, so the prompt itself is the confirmation step." Its sibling amend-head has no such interstitial step — no prompt, straight to execution — which is why it needs the explicit y-confirm as its only gate. Every other id in HISTORY_REWRITE_WORKFLOW_IDS follows that same "no prompt → needs explicit confirm" shape.

So the asymmetry is real but intentional: two different safety mechanisms (prompt-and-submit vs. explicit y-confirm) for two different UX shapes, not one workflow that fell through the cracks.

The open question is genuinely a product call, as your own confidence note says: is "review the pre-filled text, then press Enter" sufficient consent for a HEAD rewrite, or should reword-head require the same explicit confirm its no-prompt siblings get (i.e. prompt then confirm, matching how amend-head handles staged changes)? I didn't want to flip that behavior unilaterally.

What I did land: #2121 adds the registry-invariant test you suggested — every HISTORY_REWRITE_WORKFLOW_IDS entry must have requiresConfirmation: true unless it's in an explicit, documented allowlist (currently just reword-head). No behavior change; it just makes sure a future history-rewriting workflow can't ship without either an explicit confirm or a documented prompt-gate exception. Leaving this issue open for the actual policy decision.