Broker scope from live Team grants: new repositories should not need a policy redeploy #14

Problem

Every new repository an Organization's Team gets write on also needs a reviewed broker policy change: the repository id must be added to repositories and to the Workspace's repository_ids, and a new Worker version must be uploaded and deployed with the GitHub App key and Cloudflare credentials only the platform operator holds. Policy v2 (#13, unreleased) adds a live Team grant check, so a revoked grant stops minting immediately. But the static repository_ids allowlist stays ("outside the allowlist is refused before the live Team grant is even read"), so adding access still needs the operator.

GitHub is the access authority (root decisions 0147–0149). An Organization Admin who grants a Team write on a new repository should not need a platform deployment before that Team's shared Environment can use it.

Real case (2026-10-02)

A new module and its data repository were granted to two Teams on GitHub. The Teams' shared Environment could not clone them until the operator changed the policy, re-uploaded and deployed the Worker. The Organization Admin had no way to do this herself.

Proposal (needs a decision)

An opt-in Workspace scope team_grants (policy v3, or v2 with a mode): the broker mints a token for a repository when the bound GitHub Team has a live non-archived write grant on it, read at mint time as #13 already does, without a static repository_ids entry. The Organization stays the boundary (github_owner). Keep the static allowlist as the default for Workspaces that want a narrower reviewed scope. Consumers: the Machines client-side github_broker.repositories list must follow (separate Machines issue).