[shuv1337]

Why

Self-host is getting real multi-organization support, and switching organizations must keep apps, accounts, connections, groups, grants, credentials and MCP calls scoped to their organization. The shared hosted server already scopes every request to the route's organization and Cloud tests it; self-host skipped those scenarios only because it allowed one organization. Stacked on #82, which lets the root owner create the second organization they need.

What changed

• e2e/test-plan.ts: resourceIsolation, groupsIsolation and patMcpRenamedOrganization are scheduled on self-host. Their "Self-host permits one organization" exclusions are removed.
• Those scenarios, and dashboard-batch-isolation, remove their extra organization only on Cloud. Self-host has no organization removal, and each self-host scenario's server is discarded after it passes.
• dashboard-batch-isolation now runs its cross-organization batch on self-host. There the root owner creates the member's organization and invites the member as admin, because members cannot create. The member's expected role there is admin. The owner belongs to that organization, so the owner's batch answers 200 throughout. The foreign-organization 403s are unchanged.

Cloud behavior is unchanged: each Cloud branch is the original code under if (cloud). Cloud runs of these four files were not executed locally.

Verification

bun run check: exit 0.

On self-host, 4/4 passed:

• Group resource grants and account connections cannot cross organizations
• Group identities and memberships cannot cross organization boundaries
• PAT MCP calls keep their organization when its slug is renamed mid-request
• A dashboard batch answers each read with its own caller's identity, organization and role

resource-isolation.spec.ts
groups.spec.ts
pat-mcp.spec.ts
dashboard-batch-isolation.spec.ts