CB-582: bridge_status now reports an open question — say so, and keep the warning

The prompt is part of the product: CB-582 changed what bridge_status returns, so
the primary's step 5 was no longer the whole truth.

The second half matters more than the first. A nudge makes a lead more likely to
notice an ask; it does not widen the ~55s window, which is bounded by the
WORKER's own MCP client timeout, not by anything the daemon chooses. Without that
sentence a lead reads 'the ask now nudges me' as 'asking works now' and briefs a
worker to ask — which is the failure CB-582 was filed about.

CLAUDE.md

@@ -80,7 +80,9 @@ below are the procedure — run them in order, every task, not only the big ones
    of your context, your plan, or your screen.
 5. **Collect** — `bridge_poll{ticket}` → `bridge_ack{ticket, msgId}`. Answer a worker's `bridge_ask`
    with `bridge_send{turnId, content}` — **not** `sessionId`. A worker gone quiet is diagnosed with
-   `bridge_status`, never by reading its terminal.
+   `bridge_status`, never by reading its terminal; it also reports an open question and the `turnId`
+   that answers it. **A worker's ask waits ~55 seconds, and no nudge makes that longer** — so never
+   brief a worker to "ask me". Decide before you delegate, or give it an explicit default.
 6. **Verify yourself.** Re-run the build and the checks. A worker cannot run your IDE tooling, any
    forge tools it appears to have hold a blocked credential and fail, and a piped command
    (`… | tail`) hides failures behind a zero exit — never promote a worker's "clean" to a fact.