Have the agent push unready lanes before moving a channel to a cloud workspace #500

Reported while dogfooding (#5).

What happens

Moving a local channel to a cloud workspace fails if any of its lanes has uncommitted changes, is not pushed, or has no branch:

Could not move readme-hello-world
The cloud workspace starts from a fresh clone, so commit and push these lanes first, or remove them: readme-hello-world (uncommitted changes to readme.md).

The only option offered is Try again, so the person has to go back to the chat, ask the agent to commit and push, wait for the agent, and then start the move again. Usually the agent did the work in that lane, so this cleanup is a job for the agent.

The check is lanes in apps/host/src/compute.ts, which adoption runs before the move.

Expected

When Move to → cloud workspace finds unready lanes, Ace handles them:

1. It sends the channel's agent a message, starting a run, that lists each unready lane and what's wrong with it. The message tells the agent to commit and push each lane's branch to origin with lane push. The agent should not open a PR or remove lanes.
2. It waits for that run to finish while the move shows progress, for example "Waiting for the agent to push readme-hello-world…", the same way move progress works today (fix(app): show a move's progress instead of Try again while it runs #375).
3. It checks the lanes again. If they are all pushed, the move continues to the cloud workspace with no further action. If any lane is still unready, or the run fails or is stopped, the move stops, the channel stays on this Mac, and the error names the lanes that are left.

Open questions

• What to do when the agent is already running when the move starts: queue the message as a follow-up, or refuse until the run ends.
• Whether lanes with no branch get the same treatment, or still have to be removed by hand.
• A hosted channel moving to a cloud workspace (Move a hosted channel straight to a cloud workspace #499) needs the same step once that move exists.