Introduce "communities": scoped agent groups so parallel cohorts can run concurrently

[andrewsu]

Motivation

Today the only mechanism that separates groups of agents during a simulation run is the binary AgentRegistry.status (active vs inactive). To keep the Cabo cohort from generating cross-cohort proposals while the Schultz reunion cohort runs, we inactivate the Cabo bots entirely. That's a blunt instrument:

• It's all-or-nothing: an inactivated bot stops participating everywhere, even though we only wanted to separate it from one other group. (See related issue about inactive bots losing access to their own past proposals.)
• It can't express "Cabo keeps interacting among themselves while Schultz reunion runs in parallel." Right now those two cohorts can't both be live at once without their agents pairing up with each other.
• "Cohort" exists today only as a post-hoc visualization construct — date windows + ORCID lists in src/routers/public.py (Cabo retreat, Schultz alumni pilot, Schultz group alumni). There is no runtime notion of group membership; all active agents can talk to all other active agents (src/agent/simulation.py pairing logic).

Proposal

Introduce first-class communities (groups) as a runtime concept:

• A user/agent can belong to one or more communities (many-to-many).
• Users specify which communities their bot should interact in. A bot only initiates/joins discussions and generates proposals with other bots in a shared, opted-in community.
• Multiple communities can run in parallel: Cabo agents keep collaborating within the Cabo community while the Schultz reunion community runs concurrently, with no cross-talk unless a user is a member of both and opts in.

This replaces the current "inactivate the whole cohort" workaround with explicit, scoped membership.

Why this needs deep planning (open design questions)

The data model is the easy part; creation and administration of communities is where the real design work is and should be planned carefully before implementation:

Data model (sketch — to be refined)

• New Community table (id, name, slug, description, visibility, owner, created_at, …).
• Pivot agent_communities (or user_communities) for many-to-many membership, plus a per-membership "active in this community" opt-in flag so a user can be a member of a community without their bot currently interacting in it.
• AgentRegistry today has no group field (src/models/agent_registry.py) — membership should live in the pivot, not as a single column.

Administration / governance (needs decisions)

• Who creates a community? Self-service by any user, admin-only, or request-and-approve?
• Who administers it? Per-community admins/owners vs. global admins. Can ownership transfer?
• Joining: open join, invite-only, request-to-join with approval, or admin-added? How does this interact with the existing delegate / invitation flows?
• Membership changes mid-run: what happens to in-flight threads/proposals when a user joins/leaves or toggles their bot's participation? Do existing proposals stay visible?
• Defaults & migration: existing agents need to be mapped onto communities (e.g. seed a "Cabo" and a "Schultz reunion" community from the current ORCID/date cohorts). What's the default community for a brand-new signup?

Runtime / simulation impact (needs decisions)

• Pairing and thread-join logic (simulation.py) must filter candidate partners by shared community membership instead of (or in addition to) the global active status.
• Channels: today channels are global/thematic (src/agent/channels.py SEEDED_CHANNELS) and auto-joined by profile keyword. Decide whether communities get their own channel namespaces, share thematic channels but scope membership, or something else.
• Proposal generation must be scoped per community; reconcile with the existing status='active' filter in src/agent/main.py.

Visualization / reporting

• The collaboration graph cohorts in src/routers/public.py are currently date-window + ORCID hacks. Communities could become the canonical scoping mechanism for these graphs, replacing the hardcoded windows/ORCID frozensets.

Relationship to existing concepts (to consolidate during planning)

• status (active/inactive) — currently doubles as a cohort-separation hack; communities should take over that role so status can mean just "is this bot operational."
• Graph cohorts (date windows + ORCID lists in public.py).
• PILOT_LABS static list in simulation.py (organized only by institution comments today).
• Private channels / PrivateChannelMember (ad-hoc 2-party membership) — overlaps conceptually with community membership.

Scope of this issue

This is a planning/design issue, not an implementation ticket. The goal is to agree on the community data model and — most importantly — the creation/administration/governance model before writing code. Implementation should be broken into follow-up issues once the design is settled.