Let two prefixless connections share an agent when one names its issuer

[haruotsu]

Why

An agent that reads one service and writes to another is refused today when both connections declare token_prefixes: []: elimination_problems allows at most one connection per agent to accept tokens by elimination. The rule is right — two fully anonymous connections cannot be told apart, and a token from either authorization would pass as the other's — but it is blunter than the runtime it protects. Since tokens are judged by the issuer their claims name (accepts_token → issued_here), a provider whose access tokens are JWTs issued by its own host announces itself in every token. It is not anonymous at all; validate just had no way to know the tokens would arrive as JWTs.

What

• tokens: {format: jwt} on a connection says its tokens are JWTs whose iss claim names the connection's own service (its hosts and its OAuth endpoints, the same set issued_here already matched). Schema, README, and gete connections know about it.
• The runtime holds the connection to it. accepts_token refuses anything that is not such a JWT — an opaque token, a JWT whose claims cannot be read, a JWT that names no issuer or names someone else's — whatever else would have taken it. Without that, the declaration would loosen validate while promising nothing where it counts. A format this gete cannot judge (a resolved declaration outlives the gete that wrote it) accepts nothing rather than falling back to elimination.
• elimination_problems counts only connections with neither prefixes nor a declared format. One anonymous connection per agent stays the ceiling; a jwt-declaring one no longer occupies it. The remaining anonymous one is already protected from the JWT side: a JWT whose issuer names the other service is refused by accepts_token today.
• Two declaring connections that name one issuer host are refused together, for the same reason the anonymous pair is — each would accept a JWT naming the shared issuer, so neither could tell the other's token from its own. Not in the issue, but the declaration opens that route and the function exists to close it.
• Prefixes next to a declared format are reported. The format decides on its own, so the prefixes would never be read, and a reader would have to know that to see which rule the connection is held to.
• gete connections prints (none: jwt issued by this service) where it printed (none: by elimination). That difference is what decides whether an agent may hold the connection beside another, so it must not read as the elimination it replaces.
• A refusal names the promise the token missed — not the jwt this connection declares, a JWT that names no issuer — because an operator who turned the provider's setting off has every token refused at once and nothing else in the log would say why.

Zendesk

Whether a provider issues JWTs can be a per-client setting — Zendesk does so only with token expiry turned on — so the catalog must not promise it for every installation. The entry keeps token_prefixes: []; its setup says how to declare the format and what it costs, next to the setting itself: turn expiry off again and every Zendesk token is refused until the declaration goes with it.

Its examples.accepts had to go. Which of the two shapes arrives is that same setting, so an example fixing one contradicts an installation that has the other — an installation declaring the format would have seen examples.accepts: '...' is not accepted from validate for a catalog entry it never wrote. What is refused is refused either way, and the rejects list stays.

# gete.yaml
connections:
  zendesk:
    base_url: https://acme.zendesk.com
    tokens:
      format: jwt      # tokens are JWTs issued by acme.zendesk.com, nothing else

Tests

• schema: the block is accepted; an unknown format, an unknown key under it, and an empty tokens are refused
• accepts_token: a JWT from the service's own hosts, OAuth endpoints and installation root is accepted; an opaque token, a foreign issuer, a missing issuer, unreadable claims, Google's access tokens and ID tokens are refused; a foreign prefix no longer decides; an unknown format accepts nothing
• elimination_problems: a declaring connection does not occupy the elimination slot, two from different services are fine, two sharing an issuer host are reported as one pairing; the anonymous pair is unchanged
• connection_problems: prefixes beside a format are reported
• validate, end to end: zendesk + internal-api on one agent passes with the declaration and still fails without it
• resolve: the declaration travels to the runtime and refuses there
• runtime: describe_token names the unmet promise, usable_token refuses the opaque token without logging it
• catalog conformance: Zendesk promises no format for everyone, records no accepted shape, and an installation may declare the format on top of it

uv run pytest (863 passed, e2e included), ruff check, ruff format --check and mypy all pass.