cluster parity for diagram sharing

[fabracht]

Context

Phase 1 of diagram sharing is implemented for agent mode (branch diagram-sharing-phase1): share-aware access core, $DB/{e}/{id}/share|unshare|shares + $DB/{e}/shared endpoints, _shares lockdown, transitive cascade, _shares index registration, and grantee email→canonical-id resolution (resolve-existing).

Design: docs/design/diagram-sharing.md. Plan: docs/design/diagram-sharing-phase1-plan.md.

The agent path (mqdb-agent execute_with_sender) was extended, but the cluster uses a separate JsonDb code path that does not yet handle the share operations. This issue tracks bringing the cluster to parity.

Scope

• Route Share/Unshare/Shares/Shared through the cluster DB flow. The cluster uses its own JsonDbOp enum + cluster/node_controller/db_ops.rs (match request.op, ~line 382) and cluster_agent/admin.rs dispatch — not the agent Request match. This is net-new wiring, not a copy.
• Treat _shares as a partitioned entity: a grant is written/read on the resource's partition primary; check_access/share_level run where the resource lives (cluster/db_handler/).
• Apply the share-aware access check on the cluster read/update path (parity with transport_execute.rs: Read→View, Update→Edit, delete owner-only).
• Register _shares indexes at cluster startup (parity with MqdbAgent::register_share_indexes).
• _shares orphan cleanup when a diagram is deleted (cluster delete path).
• Block generic CRUD on _shares on the cluster path (parity with the agent guard).
• Grantee resolution in cluster mode — confirm the cluster handler can reach identity_crypto, or resolve before routing.

Acceptance

• mqdb dev test --sharing passes on a 3-node cluster (share / read / update / delete / cascade / discovery, cross-node).
• Agent and cluster behave identically for the share API.

Notes

• Trace the cluster $DB/... request path first — the cluster does not reuse execute_with_sender.
• Pending-grant resolution was intentionally deferred (resolve-existing only); not in scope here.