feat(sharing): external client roster on the Sharing tab (trinity-enterprise#20)

[dolho]

Summary

Surfaces the external client roster on the agent Sharing tab — outside channel users (no Trinity account) who have messaged the agent, aggregated across Telegram + WhatsApp and ordered by most-recent activity. The per-channel activity (verified_email, message_count, last_active) was already collected but never shown.

Read-only surface for the Access/Sharing redesign (epic trinity-enterprise#16). Per-client block / revoke / approve controls build on this next (trinity-enterprise#21).

Changes

• db — list_clients_for_agent() join methods (binding → chat_links) on Telegram + WhatsApp ops; exposed via the database.py facade
• service — services/client_roster_service.py: cross-channel aggregation, sort by last_active desc (never-active last), per-channel failure degradation
• api — GET /api/agents/{name}/clients (OwnedAgentByName, read-only, DB-sourced so it renders when the agent container is stopped); ClientRosterEntry model is channel-extensible
• ui — read-only Client Roster table in SharingPanel.vue
• tests — tests/unit/test_client_roster.py (5): join normalization, tenant isolation, sort/nulls-last, channel-failure degradation
• docs — requirements §44, architecture endpoint + service entries

Scope

Roster v1 = Telegram + WhatsApp (the channels recording the full email/count/last-active triple). Slack (verifications carry email but no activity counters) and VoIP (call logs) are additive follow-ups — the response model already accommodates them without a contract change.

Testing

24 passed — 5 new roster tests + existing Telegram/WhatsApp channel suites, no regressions.

Related to Abilityai/trinity-enterprise#20

🤖 Generated with Claude Code

[github-actions]

⚠️ Nightly unit-suite check skipped — merge conflict against dev.

Resolve by running git merge dev locally and pushing the result. The next nightly run will re-test once the conflict is gone.

[vybe]

Validated via /validate-pr — no schema/security issues, but CONFLICTING with dev after #1317. #1317 restructured SharingPanel.vue (operator management moved to the new Access tab; the panel was reframed around Identity Proof / access policy). This PR was built on the old standalone "Team Sharing Section" layout, so the SharingPanel.vue conflict is a semantic re-integration — the Client Roster section needs to be grafted onto the new structure (the #18/#20 Sharing redesign you scoped), not just line-merged. The backend conflicts (sharing.py imports, architecture.md table row) are trivial.

Please rebase onto current dev.

— posted via /validate-pr