Protected-project flag and CLI/provisioner push rules for live workflows

As a developer deploying with the CLI, I want pushes to a project that has live workflows to follow clear, predictable rules, so that I cannot silently overwrite a production workflow by pushing to the wrong place.

Context

Today a developer with an API token can clone a project and push it straight to the project's UID through the provisioner, overwriting whatever is there, with no notion of draft or live. With the lifecycle work, live workflows are meant to be protected. The Jun 24 planning call agreed the direction but left the rule set open. Enforcement is expected to live provisioner-side in Lightning, not in the CLI binary.

Open questions to resolve

• A "protected" flag on a project, similar to a protected branch, that blocks direct pushes and requires editing through a sandbox or draft.
• On a push to a live or protected project, should the provisioner reject, create a new draft, update an existing draft, or error when no draft exists?
• When only one workflow is deployed to a multi-workflow project, what is the fate of the sibling workflows (leave untouched, force to draft, or something else)?

Acceptance criteria

• The push-rule set is written down and agreed (reject vs create-draft vs update-draft vs error).
• Sibling-workflow behaviour on single-workflow deploy is defined.
• A protected-project concept is specced (where the flag lives, who can set it, what it blocks).
• The provisioner enforces the agreed rules with clear errors.

Status

Blocked on the rule set being defined. This blocks the real wire-format work (#4897), since honest round-trips depend on these rules. Cross-repo coordination across the Lightning provisioner, the CLI, and the spec. Do not build until the rules are agreed.

Part of #4852.

Start by reviewing the open questions, acceptance criteria, and the Jun 24 planning decision for the Lightning provisioner and CLI. Define the push, sibling-workflow, and protected-project rules before implementation; coordinate with #4897 and #4852, and treat agreed provisioner enforcement with clear errors as done.