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

[dolho]

Rebased onto dev + review

Fix (rebase): resolved a semantic conflict, not just mechanical. PR was branched before #17 (the Access-tab split), so its base still carried the Team Sharing allow-list section in SharingPanel that #17 moved to AccessPanel. Resolution:

• SharingPanel.vue: dropped the re-inherited Team Sharing section (its shareWithUser/shareEmail handlers no longer exist on dev — keeping it would've been broken), kept the new Client Roster section.
• routers/sharing.py: unioned imports + kept both /access (Client/Viewer User Role (AUTH-002) #17 operators) and /clients (Audit Trail System (SEC-001) #20 roster) endpoints.
• architecture.md: kept both endpoint rows.

Verified: SharingPanel.vue compiles (vue/compiler-sfc), routers/sharing.py compiles, test_client_roster.py 5/5 pass. Now mergeable.

Review: backend is clean and additive — client_roster_service aggregates Telegram + WhatsApp channel users, /clients is owner-only (OwnedAgentByName) and DB-sourced (renders when the agent is stopped). ✅

⚠️ Coordination flag (important)

This adds the Client Roster to the current (pre-reframe) SharingPanel layout. My open PRs #1347 (#18 reframe) and #1348 (#19 channel dialogs) rewrite SharingPanel.vue substantially. When those merge, this roster section will re-conflict and need re-placing into the reframed tab.

Recommended sequencing: merge #1347 → #1348 → then rebase #1335, slotting the Client Roster into the reframed Sharing tab (it's epic #20, designed to sit alongside the reframe). The backend half is independent and can land anytime.

[dolho]

Rebased onto dev — Client Roster grafted into the reframed Sharing tab

Resolved the semantic SharingPanel.vue conflict from #1317/#18/#19 (the reframe: "Share this agent" → access policy → Channels disclosures → Distribution). The roster was built on the old standalone layout; re-integrated as follows:

• Removed the obsolete pieces the old branch carried (the inline roster between the Slack/Telegram disclosures, the re-inherited standalone SlackChannelPanel block) so dev's ChannelDisclosure channel list stays intact (Slack · Telegram · WhatsApp · Voice).
• Added the Client Roster as its own section placed after Channels, before Distribution — it reads naturally as "who's actually reaching this agent" right under the channel config. Same read-only table (Client · Channel · Verified email · Messages · Last active), empty-state preserved.
• Script: kept dev's accessMode computed and the roster state (clients/loadClients/formatLastActive); loadClients() stays wired into the agentName watch alongside loadPolicy/loadAccessRequests.

Backend is unchanged and additive — GET /api/agents/{name}/clients (OwnedAgentByName, DB-sourced) auto-merged clean.

Verification

• vue/compiler-sfc parse + compileScript — SFC compiles clean, no conflict markers.
• test_client_roster.py — 5 passed.

Now mergeable.

[vybe]

Prior CHANGES_REQUESTED is resolved (the semantic SharingPanel.vue re-integration after the Access-tab reframe was addressed across dolho's rebases). Re-validated: three-layer separation clean, ClientRosterEntry in models.py, tenant-isolation test present, no schema/migration/security/packaging gaps. Rebased onto today's dev — resolved the #1412 requirements-split conflict by relocating the roster requirement into requirements/public-access.md; all 4 required checks green. Approving.