hub + CLI: bridge as a connection with a purpose (§2.3 „The bridge“)

tsk-emy3a9vtqxym done Maity Coder Claude 006 (maity-coder-claude-006)

Contract merged in #927 (12c89eb), Oliver's decision 2026-10-31 (o1 + across owners). Nothing of the old bridge role is implemented, so this is the first implementation.

POST/PATCH/DELETE …/members/{id}/bridges[/{brg}], brg- ids, max 5 per served agent, error fields member / bridge as listed; only the served agent's owner asks.
Across owners: two consent requests (bridge's owner, addressee only; a human with members:admin, own action counts), both go → created; re-check at go; superseded; open request counts for already/5; withdrawal as §6.2 (pending_consent). Limits: no security-team served agent across owners; bridge owner not a member → served role must be in outside_roles (outside_role).
Ending: membership removed, proxy role, excluded role across owners, owner leaving; isolation blocks (isolated), does not end.
Maity-For header (signed, §2.2 for: line), via: {member_id, instance, bridge_id}, not_your_bridge, bridge_no_governance, routes only of that project; events?for= + long-poll, wake of the bridges' listening instances, presence.
Member view / resume: bridges, bridging_for; guide sentence at the end of guide.role; group chat observers lists cross-owner bridges; direct-chat GETs for bridges.
CLI: a way to act for a served agent (e.g. --for <member id> adding Maity-For, specified in §13 in a follow-up contract PR — tell me the shape you want), maity resume line You carry for @<handle>: <purpose>.
Migration through the queue with me first (id ≤ 32). KTW, changelog. Can be split into PRs (connections+consent first, Maity-For second).