A CLI deploy changes a live workflow and records no version

As a person responsible for a live workflow, I want a deploy from the CLI to appear in the workflow's history, so that the history is the whole record rather than most of it.

Part of #4852 (Sandbox DevX epic). Phase 2, builds on version recording (#4866).

Outcome

A deploy that changes a live workflow records a version, the same as going live, promoting and restoring do.

Four things can change what a live workflow is running. Three of them record a version. A deploy from the CLI goes in through the provisioner, can change the content and can change whether it is live, and records nothing. So the history looks complete and is not, which is worse than recording none at all: someone reading it concludes nothing changed on Tuesday, and something did.

Scope

• A version recorded when a deploy changes a live workflow.
• Attributed to whoever the deploy authenticated as, and marked as having come from a deploy rather than from the editor.
• The existing three routes keep behaving as they do.

Notes

Needs a decision on what a deploy that touches twenty workflows should produce. Twenty versions is honest and noisy; one shared record is quieter and does not fit the per-workflow history.

Related to the push rules still open in #4921 and #4922, since both are about what a deploy is allowed to do to a live workflow.

Start in the provisioner path used by CLI deploys and compare it with the existing version recording for going live, promoting, and restoring. Review the decision needed for deploys touching multiple workflows, along with related issues #4921 and #4922. Done means a deploy that changes a live workflow records an authenticated, deploy-attributed version while the existing routes remain unchanged.