Give an operator's Chat sandbox their own sign-in at each service with a host

[czpython]

What changed

An operator's Chat sandbox now holds that operator's own sign-in at each service that declares a host and has OAuth endpoints, so the command line acts as that person. With a GitHub sign-in, git and gh in Chat act as the operator. An operator without a sign-in gets nothing for that service, and a Bot's sandbox never holds one.

• Github declares host = "github.com" and loses secret_name. Every GitHub sandbox entry is named by the service slug and carries the host: a build's through RepoWorkspace.get_secrets, a review's through ReviewWorkspace.get_secrets (github_reviewer when the reviewer App is connected), and the operator's sign-in in Chat.
• Chat reads the services registry for a service with a host and OAuth endpoints and adds the operator's sign-in under the service slug. It names no service.
• The issuer answers the sign-in from the stored grant and refreshes it, as it does for an MCP grant.
• A service reads the token endpoint's answer to a refresh through Service.is_grant_revoked. The default is RFC 6749's 400 with invalid_grant; GitHub overrides it with its 200 and bad_refresh_token. A revoked grant is left out of the next turn instead of failing the sandbox.
• Agent(secrets=...) refuses a field of an App key service, which issues tokens and has no field a sandbox could hold.

Needs a Drukbox with czpython/drukbox#63, which resolves an entry for github.com to its GitHub service under any name. Without it, a build's git and gh have no token.

Closes #759

[mintlify]

Preview deployment for your docs. Learn more about Mintlify Previews.

Project	Status	Preview	Updated
druks	🟢 Ready	View Preview	Oct 1, 2026, 9:39 AM

💡 Tip: Enable Automations to automatically generate PRs for you.