client/MCP: bulk share — SHARE_NOTEBOOK adds multiple users in one call

Live-verified on a scratch notebook (teng-lin-9414, torn down): SHARE_NOTEBOOK accepts multiple user entries in one call. The client's add-user path (_sharing.py:178) sends exactly one email per call, but the wire slot is a list.

Verified wire shape

Single add-user puts one entry in the index-1 list:

[[nb_id, [[email, None, permission]], None, [msg_flag, welcome]], notify, None, [2]]

The entry list takes many:

[[email1, None, 3], [email2, None, 3]]   # two VIEWER grants in one call

✅ Shared a notebook with [email protected] + [email protected] in a single SHARE_NOTEBOOK call — get_status().shared_users returned both (plus owner).

Proposal

• Client: let sharing.set_user / add-user accept a list of (email, permission) grants → one RPC (keep single-email overload).
• MCP: share_set_user gains a plural mode (this is a sharing-widening op → keep the confirm=true gate; preview should list every grantee).
• Value: "share with the whole team" collapses from N round-trips (and N welcome emails / N notifies) to one.

Notes

• Mixed permissions per call work (each entry carries its own permission code).
• notify / welcome-message flags are per-call, not per-user — call it out in the API.
• New _idempotency_policy.py slot; ADR-0025 schema-char budget on the MCP side.

Part of the batch-capability audit: confirmed bulk ops are DELETE_SOURCE (#1995), ADD_SOURCE (#1998), DELETE_NOTE (#1999), and now this; single-only are DELETE_NOTEBOOK / DELETE_ARTIFACT (PR #1997).