Tell the Expert over MQTT when the workspace is ready, and unblock the go-ahead

The Expert provisions the workspace and then carries on talking to the user while it starts up. It can't offer to implement anything until the workspace actually exists, so it needs to know when that happens.

The chain, all over PubSub:

```
forge ──→ UI instance is ready
UI ──→ Expert silent system message on the chat topic
Expert ──→ user "your workspace is ready, shall I go ahead?"
user ──→ Expert go-ahead
```

So the readiness signal doesn't gate anything by itself. It unblocks the Expert's ability to *offer*, and the user still decides when building starts. Two gates: the go-ahead, then plan approval before anything gets written.

### Pieces

* **Forge publishes when an instance finishes starting.** On a per-user topic the first-party UI already subscribes to.
* **The UI relays it to the Expert** as a silent system message on the chat topic, not shown as a chat bubble.
* **The Expert holds back the go-ahead** until that message arrives, then offers it.

### Done when

* The Expert learns the workspace is ready without asking for it and without any request from the browser.
* It doesn't offer to implement before the workspace exists.
* The user, not the Expert, decides when building starts.

### Worth knowing

No polling and no HTTP. Everything on the existing PubSub pattern.

The correlation is free because of where it happens. The UI holds both the chat session id and the browser session id, so it can receive a forge event addressed to the user and republish it into the right conversation. Forge never needs to know a chat session exists, which is why this doesn't need any backend session mapping.

This is the first-party path, so it has nothing to do with `BrowserSession`, tab presence or the MCP toggle. Those exist for third-party MCP clients that don't know what the user is looking at. The Expert is in the same browser as the conversation.

Worth settling in this issue: which topic forge publishes on, and the ACL for it. Per-user rather than per-tab is the obvious shape, so every tab that user has open hears it, which is fine for "your workspace is ready".

There's an existing pattern to copy for the browser publishing into the chat topic: `stopInflightChat` in `product-expert.js` builds a chat-request topic and publishes an abort onto it. A relayed system message is the same move with a different payload.