[ADR-060 Phase D] Tenant-boundary role composition + the named IDOR-shaped adversarial test

[cuttlefisch]

Part of #60-epic.

Depends on: #60-C

Per-KB roles (ADR-017/018) compose across tenants a principal is a member of; tenant quotas apply regardless of role; no new cross-tenant trust is created.

This phase's primary, highest-priority test (per real CVE precedent — Gitea CVE-2026-27771/CVE-2026-58444, Vaultwarden CVE-2026-27898, both root-caused to "authorization checked too late, on a path the addressing layer didn't anticipate"): a request correctly addressed at tenant A's own instance via Phase A's addressing, whose payload references a raw node ID actually belonging to a DIFFERENT tenant, must be rejected at ID-resolution time — not served just because the outer RPC was addressed correctly.

DoD

• Role composition across tenants implemented, no new cross-tenant trust created
• PRIMARY adversarial test (IDOR-shaped, named): cross-tenant raw-ID reference in an otherwise-correctly-addressed request is rejected at ID-resolution time
• Adversarial test: owner-on-KB1/guest-on-KB2 principal rejected on KB2 regardless of quota headroom
• Adversarial test: forged/rotated-key signature rejected identically to pre-multi-tenancy behavior

[cuttlefisch]

Resolved — see `docs/adr/060-daemon-multi-tenancy.md`'s new "Implementation note (added
during Phase D implementation)" for the full explanation. Tackled ahead of Phase C
(reordered intentionally, by user decision): Phase D was already well-specified in the ADR
and named as this ADR's own single highest-priority adversarial test, while Phase C's
stated premise turned out to need correcting first (see the separate Phase B/C
Implementation Note) — no need to block D on C.

Each of the three named adversarial cases was written and run against the current
architecture before assuming new enforcement code was needed (same discipline that
resolved Phase B), and each resolved differently:

• The IDOR case (this issue's named PRIMARY test) is a genuine structural property of
  Phase A's own addressing, not a bolted-on check: `snapshot_query_layer`/`snapshot_store`
  resolve the `instance` address to one specific `Arc` before any inner ID
  is looked at, so every subsequent lookup is backed by only that store's own relations —
  there's no shared ID space to leak across. Proved with a real cross-instance ID collision
  (`handler::tests::idor_a_valid_instance_address_never_resolves_a_different_tenants_id`):
  a node inserted directly into tenant B's store, requested via a validly-addressed tenant
  A request, resolves to `Null` across `kb/get`/`kb/links_from`/`kb/links_to`, with a
  third uninvolved tenant C included per principle feat: editor polish, version bump & new features (v0.3.0) #14's N-way requirement.
• Role composition: per-KB roles are derived per-collection in
  `daemon/src/collab_handler/mod.rs`'s `kb_access` — an entirely separate daemon listener
  (mTLS collab) from the KB Unix-socket path Phase A/B's addressing touched (which has no
  principal/role concept on it at all, by design). No existing test explicitly proved a
  single principal holding different roles on two different KBs doesn't leak the stronger
  one across the boundary, so
  `collab_handler::tests::collab_handler_cross_kb_role_isolation_tests::
  owner_of_one_kb_is_not_owner_of_another_kb_where_only_viewer` closes that gap (bob, real
  Owner of his own KB, denied an Owner-only action on a second KB where he's only Viewer;
  the reverse also verified).
  Honest caveat on this issue's own "regardless of quota headroom" DoD wording: Phase
  C's quota mechanism doesn't exist yet (see the corrected Phase C scope in the same
  Implementation Note), so there is no quota headroom for this test to be "regardless of" —
  the role-isolation property itself is verified; the quota-interaction half of that
  specific DoD phrasing will need re-checking once Phase C actually ships a quota mechanism.
• Forged/rotated-key signature: already covered, pre-existing, unrelated to this ADR —
  `shared/sync/src/membership.rs`'s `tampering_any_field_breaks_the_signature` (+
  `forged_rebind_wrong_signer_is_rejected` and several `collab_handler` forged-signature
  tests) confirmed by direct reading, not duplicated.

Verified locally and will be confirmed in real CI (daemon workspace: 104+156 tests passing,
clippy -D warnings clean, fmt clean).