#31995 Cloud start: wait for the tab capability after updating an outdated machine

Summary

The no-folder Cloud start updates an outdated machine before opening the chat tab (#31145). It waited only for the machine's link to change, not for the capability it needed. A new link can come up before its handshake advertises agent-session-tabs-v1, so the open was refused although the update had worked.

A DEV end-to-end capture of a799d97a showed this: the first start failed with "this machine's cmux-tui cannot hold agent chat tabs yet: update it", and the next send's retry on the same machine succeeded.

CloudOutdatedMachine.updateBeforeUsingCapability now waits, still bounded by 90 s, for holds() itself. holdsTabs reads the observable daemon store's identity, so the wait wakes on the new handshake rather than polling. The link parameter is gone, so CmuxNextApp loses one line.

Leo's ask (the no-project Cloud chat): "i want us to be able to do this too".

Testing

• New CloudOutdatedMachineTests.aNewLinkWithoutTheCapabilityYetIsWaitedFor: the update returns, and the capability arrives one turn later.
  • On base, the old wait returns at once on the link change: holdsTabs is false at return, and the open is refused.
  • On this head, it waits until the capability arrives.
• The existing three tests still cover update-then-capability, a bounded timeout and an already-current machine.
• prepush-gate.py: no new violations, app_lines -1.

Observed / Not run

• Observed: the capture result above, and the prepush gate.
• Not run yet: the Swift suite and the app compile, which run on the fleet after push.

Changelog

Fixed: a new Cloud chat no longer fails its first start right after the machine updates.

Agent session: agent session

🤖 Generated with Claude Code

---

^{Need help on this PR? Tag @codesmith-bot with what you need.}

---

Summary by cubic

Fixes the no-folder Cloud start so a freshly updated machine no longer refuses its first chat open. The update wait now checks for the agent-session-tabs-v1 capability itself, not just for the link to change; a new link can come up before its handshake advertises the capability, which previously caused the open to be refused even though the update had succeeded.

• CloudOutdatedMachine.updateBeforeUsingCapability now waits on holds() (bounded by the same 90 s), waking on the new handshake via the observable daemon store instead of polling.
• The unused link parameter is removed from the method and its call site.
• Adds a test where the capability arrives a turn after the link change; the existing tests for update-then-capability, timeout, and already-current machines still pass.