PluginContext has no first-class provider for "my org co-members"

[gg-risa]

Problem

PluginContext has no provider that lets a plugin ask "who are my active co-members across the organisations I belong to" — the operation any recipient-picker / sharing feature needs.

What exists today:

• authDataProvider — only exposes the current user (identity/permissions), nothing about other members.
• userManagementProvider — has getAllUsersWithRoles / searchUsersByEmail, but it's explicitly admin-only (global user directory for role management), not usable by a regular user's plugin.
• supabaseDataProvider — the generic select/rpc escape hatch every plugin falls back to.

The organisation plugin itself doesn't register a plugin-to-plugin API (registerPluginAPI) either. It just calls two raw RPCs directly: get_my_organisations then list_organisation_members per org (OrganisationRepository.kt). There's no single call to get "all my co-members across every org, deduplicated."

Evidence this is a real gap

The screenshot-share plugin needed exactly this for its "send to teammate" recipient picker, and had to add its own new Supabase RPC (list_shareable_recipients, in BossConsole/supabase/migrations/20260824000000_screenshot_shares.sql) that:

1. Joins organisation_members twice to find active co-members across every org the caller belongs to
2. Dedupes by user id
3. Excludes the caller

This is exactly the kind of thing a shared PluginContext provider should offer, instead of every sharing/recipient-picker plugin hand-rolling its own SECURITY DEFINER RPC and migration.

Suggestion

Add something like:

interface OrganisationMembersProvider {
    suspend fun listCoMembers(query: String? = null, limit: Int = 50): Result<List<CoMember>>
}

exposed as PluginContext.organisationMembersProvider, backed by the same query the new list_shareable_recipients RPC already implements (org-scoped, active-members-only, no global user directory). Plugins like screenshot-share could then drop their bespoke RPC/migration entirely.

[gg-risa]

❯ create an issue on boss plugin api

Called boss

Filed: #42 (#42) — proposes an organisationMembersProvider on PluginContext so plugins like screenshot-share don't need a bespoke RPC/migration just to list org co-members.

✻ Sautéed for 25s

❯ [Image #1] check this error
[Image #1]

This is the same root cause we already diagnosed earlier: PGRST202 because the screenshot_shares migration (which creates list_received_screenshots, list_sent_screenshots, etc.) was never pushed to the live boss-main Supabase project — PostgREST's schema cache has no record of these functions, so every call fails immediately.

Nothing new here — it's still waiting on that migration push, which is still blocked on the DB password for db.pcnwqamqdnsadranufjv.supabase.co. Once you provide that, I'll run it and this error goes away.

[arjun28115]

Taking this, unless @gg-risa or anyone else is already on it. Checked first this time: no open PR in this repo references #42, and nothing in src matches coMember, OrganisationMembers, listCoMembers or shareable_recipients, so the gap is still open on main at 4dfd0f4.

Scoping it to the API surface only, which is what this repo can carry:

• OrganisationMembersProvider with listCoMembers(query, limit): Result<List<CoMember>>, matching the shape you suggested and the Result<...> convention UserManagementProvider and DownloadDataProvider already use.
• A credential-free CoMember, deliberately narrower than UserData: identity and display fields plus the organisation ids the membership came from, and nothing that carries permissions or tokens. The point of the issue is that the existing escape hatches hand out more than a recipient picker needs.
• PluginContext.organisationMembersProvider as a nullable val with get() = null, like the other 51 providers. That keeps it additive: an existing implementor that does not override it compiles and links unchanged, and a plugin that asks for it on an older host gets null rather than an AbstractMethodError.

I will run apiCheck and regenerate apiDump so the additive claim is backed by the binary-compatibility validator rather than asserted, and leave version = alone for the release workflow's bump-on-merge.

Two things I am explicitly not doing, so nobody waits on them from me:

No implementation. The backing query belongs to whoever owns organisation data, and list_shareable_recipients in BossConsole/supabase/migrations/20260824000000_screenshot_shares.sql already does the join, dedupe and self-exclusion this needs. This PR gives that implementor somewhere to land, the same way #47, #48 and #49 landed the terminal-tab surface before terminal-tab implemented it.

No registerPluginAPI on the organisation plugin. You noted it does not register one; that is a separate call about whether this belongs on PluginContext or as a plugin-to-plugin API. I have read your evidence as favouring PluginContext, since the screenshot-share case shows a second plugin needing it. Say so if you meant otherwise and I will rework it.