Personal opt-in for agent-initiated deploys

Agent writes land as undeployed editor changes and stop there. A person has to press Deploy before the agent can see whether the change worked, which makes them the transport between every edit and its consequence.

That is deliberate. A deploy has immediate live effects, so a person pressing it is the confirmation step. It is also the largest single cost when getting set up, and in demos and PoCs where nothing is in production yet.

This grants nobody new access. Deploy permission already comes from the user's team role (`project:flows:edit`, Member and above) and, for third-party agents, the scope of the token they connect with. Both still apply. What changes is whether the person is asked to confirm each one.

### Who

* Any user who already holds Member or Owner in the team, for their own account only. Viewer and Dashboard-only users cannot deploy today and that does not change.
* Covers both FlowFuse Expert and third-party agents connected over the MCP servers.
* A third-party agent is additionally bound by its own token: a read-only token cannot deploy whether or not the setting is on.

### How

* A per-user setting, off by default. Nobody is opted in by an upgrade or by a teammate.
* Enabling it requires acknowledging a disclaimer at that moment. Turning it off takes effect immediately.
* With it on, an agent that has written flows deploys them itself and reports the result back into the conversation.

### Expected result

* A multi-step build completes without the person clicking Deploy between steps, and the agent can read back the consequence of its own change.
* For anyone who has not opted in, nothing changes.
* Every deploy stays attributable to both the agent and the user it acted for.

### Auditable

* The setting being turned on or off is an audit entry, against the user who did it.
* Each agent-initiated deploy is an audit entry, identifying the agent and the user it acted for.
* To confirm: the MCP route in this repo writes no audit entries itself, so the sink may be the gateway rather than the platform audit log.

### Legal

* Indemnification in the existing agreements already covers what a customer builds or instructs an agent to build. No new contract terms needed.
* What is needed is an explicit statement at the point of enabling, and the same statement in the docs: with this on, deploys happen without review, and the consequences sit with the user who enabled it.
* Open for review: whether the first-party agent needs different wording from a third-party one, given it is a product we provide rather than a tool the customer brought.

### Worth knowing

The setting is per user rather than per team. The person who would have pressed Deploy is the one who decides to stop pressing it.

Team-scoped resources such as FlowFuse Tables and the team broker are reachable from any instance in the team, so a deploy's effect is not confined to the person who enabled it. That is already true of every manual deploy. A team-level policy can gate this as well later, and should default to permitted so existing opt-ins keep working.

Start by locating the per-user settings entry point, the existing deploy permission checks, and the MCP route mentioned in the issue. Trace how deploys and setting changes are audited, including whether the sink is the gateway or platform audit log. Done means the opt-in disclaimer and default behavior, permission and token limits, agent/user attribution, and audit requirements are covered for both agent types.

Written by the indexing model from the issue text.