bregctl dev token: issue a synthetic user token through an interactive application

[jeremi]

Use Case

Scripted tests and verifiers for a browser host need an access token for a synthetic user through an interactive application registered in dev-clients.yaml: the same token the host would receive after a person signs in, so the host's session checks (client_id, audience, claims) apply.

What we hit

bregctl dev token <client> issues client-credentials tokens for registered clients only. For a synthetic user there is no supported path, so test tooling drives ThunderID's sign-in flow API directly:

1. GET /oauth2/authorize with resource and PKCE, which redirects to the gate with an auth ID and execution ID;
2. POST /flow/execute with the execution ID, which returns a view with a challenge token and the credential action (the first response also carries FET-1081 No live SSO session beside a normal view);
3. POST /flow/execute with the action, username, password and challenge token, which completes with an assertion;
4. POST /oauth2/auth/callback with the auth ID and assertion, which redirects to the application with a code;
5. the ordinary code exchange.

That sequence is undocumented upstream behavior of the pinned image and will break silently when the image moves.

Proposed Behavior

bregctl dev token --application <id> --user <username> [PROJECT] performs the authorization-code flow for a declared synthetic user against the session's issuer and writes the token (or the full token response) to an owner-only file, like the existing token command. The Stack owns the flow details and updates them with the pinned image.

Boundaries

• Synthetic users of a local dev session only; never usable against a non-dev issuer.
• No token or password on stdout; file output only, owner-only permissions.

Related: #1083 (documenting the dev issuer token shape).