feat(code): support multi-team workspace routing

docs/code/relay.md

@@ -88,7 +88,7 @@ devintern worker
 
 The worker detects the workspace pairing and starts the relay connection automatically alongside its normal polling. Both `worker init` and `worker connect` store relay state under the workspace home.
 
-For Linear, Asana, Trello, or Azure DevOps, set that tracker's credentials in the workspace `.env` first, then run the matching connect command below. Jira needs no extra Jira env for registration: connect prints a private ingest URL for one-time admin webhook setup.
+For Linear, Asana, Trello, or Azure DevOps, set that tracker's credentials in the workspace `.env` or a team's `env_file` / inline `[teams.env]`, then run the matching connect command below. Jira needs no extra Jira env for registration: connect prints a private ingest URL for one-time admin webhook setup.
 
 ## Commands
 
@@ -102,9 +102,13 @@ For Linear, Asana, Trello, or Azure DevOps, set that tracker's credentials in th
 | `devintern worker connect jira`         | Print the one-time Jira admin webhook setup with your private ingest URL  |
 | `devintern worker connect status`       | Show relay status and workspace repositories still awaiting verification |
 
+In a multi-team workspace, `devintern worker connect linear --team growth` selects that team's credential layers. If exactly one team uses the requested tracker, `--team` is optional and the CLI selects it automatically. The flag is invalid for GitHub and status because those targets are workspace-wide.
+
+Current tracker envelopes identify their tracker type but not an individual team registration. When more than one team uses the same tracker type—for example, two separate Jira sites—`worker connect jira` refuses registration and those teams continue using their isolated polling loops. The worker also ignores an ambiguous same-tracker task envelope rather than assigning it to the first matching team. GitHub repository events and teams using distinct tracker types are unaffected.
+
 Linear deliveries are verified with a signing secret generated on your machine. Asana deliveries are verified with the hook secret from Asana's registration handshake. Trello, Azure DevOps, and Jira deliveries carry no usable signature, so their authentication is the unguessable ingest URL itself: keep it secret, and re-run connect to rotate it.
 
-`worker connect` stores the shared pairing under the workspace home. It skips repositories whose immutable GitHub repository IDs are already verified, continues through the remaining repositories if one pairing fails, and reads tracker credentials from the workspace `.env`. Explicit shell environment variables retain precedence over that file.
+`worker connect` stores the shared pairing under the workspace home. It skips repositories whose immutable GitHub repository IDs are already verified and continues through the remaining repositories if one pairing fails. Tracker connect uses the selected team's credential layers when applicable; otherwise it reads the workspace `.env` with explicit shell variables taking precedence.
 
 ## Environment variables
 
@@ -118,7 +122,7 @@ Linear deliveries are verified with a signing secret generated on your machine.
 
 ### Per `worker connect` target
 
-These are the same credentials you already use for that tracker. Set them in the workspace `.env`. GitHub connect uses every unpaired GitHub repository in `workspace.toml`. Jira connect mints the ingest URL and prints admin setup steps without calling the Jira API.
+These are the same credentials you already use for that tracker. Set them in the workspace `.env`, or use `--team <name>` to compose that team's `env_file` and inline env. GitHub connect uses every unpaired GitHub repository in `workspace.toml`. Jira connect mints the ingest URL and prints admin setup steps without calling the Jira API.
 
 | Target         | Required env vars                                               | Notes                                                           |
 | -------------- | --------------------------------------------------------------- | --------------------------------------------------------------- |

docs/code/worker.md

@@ -300,7 +300,7 @@ In the standard setup, pair the workspace with the relay and install the central
 
 ## Instant events with the relay
 
-Polling reacts within one interval (about a minute). On its default path, `worker init` offers to sign in and pair the workspace with the [DevIntern relay](./relay.md), including GitHub and the active tracker. Events then reach the worker within seconds as reference envelopes (never code or comment content). While relay long-polls are healthy, review and mention acquisition yields to relay and runs only a 30-minute safety sweep; PR lifecycle and conflict reconciliation continue at the normal polling interval. If relay delivery stops, normal feedback polling resumes after a short grace period. Events from different acquisition paths for the same PR are serialized and collapsed into one follow-up check, so fallback coverage cannot start overlapping agent runs. Run `worker connect` after adding repositories or to add or rotate tracker registrations.
+Polling reacts within one interval (about a minute). On its default path, `worker init` offers to sign in and pair the workspace with the [DevIntern relay](./relay.md), including GitHub and the active tracker. Events then reach the worker within seconds as reference envelopes (never code or comment content). Multi-team polling uses isolated clients and cursors; use `worker connect <tracker> --team <name>` when one team owns that tracker type. Multiple teams using the same tracker type remain polling-only until relay envelopes carry team registration identity. While relay long-polls are healthy, review and mention acquisition yields to relay and runs only a 30-minute safety sweep; PR lifecycle and conflict reconciliation continue at the normal polling interval. If relay delivery stops, normal feedback polling resumes after a short grace period. Events from different acquisition paths for the same PR are serialized and collapsed into one follow-up check, so fallback coverage cannot start overlapping agent runs. Run `worker connect` after adding repositories or to add or rotate tracker registrations.
 
 ## Seeing what the worker did