PRD: User-managed resolver org routing for multi-org identities (deprecates Git org claims) #1092

User Problem

When my connected identity (GitHub, GitLab, Bitbucket, Azure DevOps, Jira, Slack, and so on) belongs to two or more OpenHands organizations, a resolver request is routed by org claims. A super admin must claim each provider org or workspace for one OpenHands org. Claims don't scale, because every integration has its own hierarchy (GitHub orgs, Jira sites, Slack workspaces). Super admins end up managing routing for users who could decide it themselves. Finally, as an end-user, it's not obvious which org my request went to until I open the conversation.

This only applies to scenarios where a connected identity belongs to two or more organizations

The resolver routing setting should ONLY apply to scenarios where a connected identity belongs to two or more organizations. If the identity belongs to only one organization, then resolver routing is not required because the conversation should start in that SINGLE organization.

Scenarios

• I belong to "Acme" and "Acme-Research". I mention @ openhands on a GitHub PR, an Azure DevOps work item or a Jira ticket. I want the conversation to land in the org I choose.
• I'm active in one org all day, and a Slack mention should follow me there without any setup.
• I'm a consultant in three orgs and want all resolver requests to go to my main client org, whichever org I'm viewing in the UI.
• I mention OpenHands on a ticket, and the "I'm on it!" reply tells me which org or workspace is handling it. I can spot a misroute right away.
• My admin had claimed our Git org before an upgrade. After the upgrade, my requests follow my own setting (Last active organization by default), not the old claim.
• A team needs fine-grained routing, such as by repo, label or channel. We use event-driven automations with filters instead of resolver routing.

I Can...

• I can open the User Settings page and find a "Resolver organization" setting. The page indicates:
  • this setting ONLY applies to scenarios where Built-in Integration identities (e.g., GitHub:jdoe1) is connected to two or more Organizations (e.g., DevOps Org, Engineering Org)
  • this setting is global, meaning it applies to all organizations I'm part of.
• I can choose Last active organization. Resolver requests go to the org I most recently used. This is the default, so routing works without setup.
• I can choose A specific organization. I pick one from a dropdown of the orgs I belong to, and all resolver requests default to it.
• I see the same setting and behavior across all built-in resolver integrations: GitHub, GitLab, Bitbucket Cloud, Bitbucket Data Center, Azure DevOps, Jira Cloud, Jira Data Center and Slack.
• I see the destination in the immediate acknowledgment on every integration:
  I'm on it! {{User}} can [track my progress here] in the {{Acme}} Organization.
  I'm on it! {{User}} can [track my progress here] in the Personal Workspace.
  The link follows each platform's markup (Markdown for GitHub, GitLab, Slack, Bitbucket and Azure DevOps; wiki syntax for Jira). The "continue tracking" follow-up messages show the same destination.
• I can rely on the new behavior from the moment the upgrade completes. Claims are never consulted, and no user or admin action is needed.
• If my chosen org is suspended, or I'm removed from it, I get a clear error or a fallback to Last active organization, rather than a silent reroute to a personal workspace. Suspended-org protections stay enforced.
• As an org admin, I no longer see or manage Git organization claims. The "Git conversation routing" section is gone from org management.

Why It Matters

• Removes routing work from super admins, and gives users control where they have the context.
• One consistent routing model across all built-in resolver integrations replaces per-integration claim logic, with no dual-mode period to support.
• Naming the destination org in the acknowledgment makes routing visible and builds trust. It also catches a wrong default right away, which matters most when the setting is global.
• Gives a clear boundary: built-in resolvers handle simple "mention OpenHands" flows, and the event-driven automation server handles fine-grained routing.

This issue was drafted by an AI agent (OpenHands) on behalf of the requesting user.