v4.4.0 — Broadcast: regex targets and summary counters

Minor on top of v4.3.0. Two additions on the broadcast feature, both pure additions.

Regex in clientId

clientId on every public tool accepts a /body/flags literal in addition to plain strings and arrays. The regex is matched against connected client IDs and expanded into the broadcast envelope.

call({ clientId: "/^ios/",            tool: "host__screenshot" })   // every connected iOS client
call({ clientId: "/./",               tool: "host__screenshot" })   // every connected client
call({ clientId: ["/^ios/", "android-2"], tool: "host__screenshot" }) // unioned with literals

Same /body/flags slash syntax already used by fiber_tree hook filters and log_box ignore patterns — agents that know the form from one place can reuse it here. Zero matches and malformed regex return an error up front. Unconnected literals still fall through to per-client errors in the broadcast envelope (matches the not-fail-fast contract).

For list_tools and describe_tool the regex behaves as a narrowing filter (canonicalisation pool / listing subset) rather than a broadcast trigger.

Summary counters in broadcast envelopes

Every broadcast response now carries top-level counters so the agent can pick out failures without scanning perClient:

• call text-only → { okCount, failedCount, results: [...] }
• call with images → prefixed by a Broadcast: N ok, M failed (T clients). text block before the per-client ## <clientId> chunks
• wait_until → { ok, okCount, failedCount, perClient: [...] }
• assert → { pass, passedCount, failedCount, perClient: [...] }

totalCount is intentionally omitted — it's just perClient.length, and one less number saves a token per response.

Compatibility

Pure addition. Existing clientId: "ios-1" calls keep the exact single-client shape (no regex chars in default IDs like ios-1/android-2, so detection is unambiguous). Existing broadcast responses gain the counter fields but keep results / perClient unchanged — old parsing keeps working.