### Background

[Add links to any resources relevant to this PR, such as Jira tickets, Slack threads and/or discussion docs.]

### Release title & description

[Add a release title and description that concisely and accurately describe your change(s). This will be published when the PR is deployed. For more details see the [Slite guide](https://root-platform.slite.com/app/docs/ZJf__sYlkh/Deploy-a-Workbench-CLI-tool-PR) on deploying Workbench PRs].

### Version bump & rationale

**New version:** [X.Y.Z]

[State whether this is a **patch** / **minor** / **major** bump and why. patch = bug fixes or internal changes · minor = backwards-compatible features · major = breaking changes. CI fails the PR if `package.json`'s version is not strictly greater than `main`'s — bump with `npm version <patch|minor|major> --no-git-tag-version`.]

### What could this PR break and how are you going to ensure that those things do not break?

[Think about what this PR could possibly break, and list your thoughts here. Be sure to factor this into the testing plan below too, to ensure you're mitigating against all known risks. **Note**: Include a discussion of backwards compatibility: could your changes break any workflows for users that cloned product modules with previous versions of Workbench?]

### What's the testing plan?

[Detailed description of testing steps and test cases here. This should be in an easy-to-follow checklist format, and should include any pre-test steps (i.e., data setup). If steps are missing, the PR _will_ be rejected. The reviewer is expected to check off each item as they complete it.]

### Any other dependencies for go-live? (link to platform PR?)

- **[dependency]:** [description]

### Any documentation or guides changes that need to be made?

- **[section]:** [description]

### Author checklist

- [ ] Have you assigned a reviewer and notified them?
- [ ] Have you included a release title and description?
- [ ] Have you bumped the version in `package.json` and explained the patch/minor/major rationale in the "Version bump & rationale" section?
- [ ] Have you ensured that your changes are backwards compatible and will not break any workflows for existing users?
- [ ] Have you handled all errors and edge cases? This includes proper `try/catch` blocks, and user-friendly error messages.
- [ ] Have you added sufficient logging? This includes Slack messaging for critical events, and `console.debug`'s for useful debugging information.
- [ ] Have you written at least 1 test case for this code (if applicable)?

### Reviewer checklist

- [ ] The release description is concise and accurate, and the style and tone are appropriate for external publication.
- [ ] All risks associated with these changes, including backwards compatibility, have been adequately identified and explained in the description.
- [ ] All risks associated with these changes, including backwards compatibility, have been adequately covered by either the testing plan, or code tests.
- [ ] All PR comments have been explicitly acknowledged and resolved.
- [ ] _I am hereby comfortable that this PR can be merged and published._

### 🤖 Claude review controls

Tick a box to (re-)trigger a Claude review. The checkbox listener picks up the tick, fires the workflow, and auto-unticks the box so it's reusable.

- [ ] `/review` — all four (security · coverage · breaking · quality)
- [ ] `/review security`
- [ ] `/review coverage`
- [ ] `/review breaking`
- [ ] `/review quality`