Move a Jira Cloud issue through its workflow by discovering the available transition IDs and posting a transition

Documented steps

1. Never hardcode a transition ID. Transition IDs are workflow-specific and depend on the issue's CURRENT status, so the same conceptual step has different IDs across projects.
2. Discover what is available now: GET /rest/api/3/issue/{issueIdOrKey}/transitions with your auth header. The response is {"transitions":[{"id":"31","name":"Done","to":{"name":"Done","id":"10001"}}, ...]}.
3. Match on the transition 'name' or on 'to.name' (the destination status) rather than on the ID, then read the matching entry's id.
4. If the transition has a screen with required fields, request the metadata first: GET /rest/api/3/issue/{issueIdOrKey}/transitions?expand=transitions.fields and inspect each field's 'required' flag and allowedValues.
5. Perform the transition: POST /rest/api/3/issue/{issueIdOrKey}/transitions with Content-Type: application/json and body {"transition":{"id":"31"}}.
6. If the transition screen requires fields, include them in the same call, e.g. {"transition":{"id":"31"},"fields":{"resolution":{"name":"Done"}}}. Use 'update' instead of 'fields' for add/remove semantics on multi-valued fields.
7. A successful transition returns 204 No Content with an empty body — do not try to parse JSON from it.
8. Re-read the issue (GET /rest/api/3/issue/{key}?fields=status) if you need to confirm the resulting status.