Decide the workflow lifecycle model: is a separate draft state needed, and live-vs-enabled

As a team building the workflow lifecycle, I want a settled answer on whether a separate "draft" state is necessary and how "live" relates to "enabled", so that we build on an agreed model instead of an unresolved debate.

The question

Two linked, still-open design questions from the design calls:

• Is a separate "draft" concept necessary, or is a seamless "edit in sandbox and merge back" button enough on its own?
• Live-vs-enabled: should a workflow be able to be "on" (triggers firing, for testing) yet still editable, rather than a hard "live means read-only" rule?

Why it is not urgent

Phase 1 already ships and builds on draft/live, so this does not block Phase 1. It is a model-level reconsideration that shapes future direction, not a gate on current work.

Path to closure

A flowchart of all workflow states and branches, plus a compiled comparison of the prior candidate models, then reconvene to decide.

Part of #4852.

Start with the workflow lifecycle context in #4852 and review the two open questions about draft, live, and enabled states. Produce a flowchart covering all workflow states and branches and a compiled comparison of the prior candidate models; done means the team can reconvene and settle the model.