integration: support provider-defined OAuth attempt expiration #36954

Summary

V2's integration service applies a fixed ten-minute lifetime to every OAuth attempt, even when an OAuth provider returns an authoritative expiration for an authorization or device code. This can terminate a valid provider flow before its advertised expiration.

Environment

• opencode version: v0.0.0-next-15564
• OS: Darwin 25.5.0, arm64
• Terminal: Ghostty (TERM=xterm-256color, COLORTERM=truecolor)
• Shell: /bin/zsh
• Install/channel: next, local V2 development checkout
• Active plugins: global config has no configured package plugins; local plugin files are present under ~/.config/opencode/plugin/

Reproduction

1. Register an OAuth integration method whose authorization callback remains valid for longer than ten minutes, such as a device flow with a provider-supplied expires_in > 600.
2. Start an OAuth connection attempt.
3. Wait until the integration service's fixed ten-minute deadline passes, but remain within the provider's advertised authorization lifetime.
4. Complete the provider authorization.

Expected Behavior

The integration attempt should remain pending until the provider-defined authorization expiration, subject to a reasonable platform safety limit. Providers that do not supply an expiration should continue using the integration service's default lifetime.

Actual Behavior

Integration.connection.oauth always sets the attempt expiration to created + Duration.minutes(10). The scrubber expires the attempt and closes its scope at that deadline, interrupting the callback even if the upstream authorization or device code is still valid.

Additional Context

The fixed lifetime is defined by attemptLifetime in packages/core/src/integration.ts and is applied after the provider's authorize implementation returns.

This surfaced while porting xAI OAuth to V2. The xAI device endpoint supplies expires_in, and the provider poller can honor it internally, but the enclosing integration attempt may still terminate first. This is not xAI-specific; any OAuth device or browser flow can have a provider-defined validity period that differs from ten minutes.

A generic solution would be:

• Add an optional absolute expiresAt timestamp to OAuthAuthorization.
• Let provider implementations set expiresAt from authoritative response fields such as RFC 8628 expires_in.
• Use expiresAt for the attempt's reported deadline and scope cleanup.
• Preserve the current ten-minute default when it is omitted.
• Optionally clamp provider deadlines to a separate, documented platform safety maximum.
• Add tests for omitted expiration, expiration shorter than the default, expiration longer than the default, cancellation, and scope cleanup.

An absolute timestamp is preferable to another duration because authorization validity may begin when the provider issues the device code, before the provider's authorize effect returns.