Increase maximum token_expires_at for runner tokens from 15 days to 21 days

Problem to solve

When creating a runner token via POST /api/v4/user/runners, the token_expires_at parameter is currently capped at 15 days in the future (introduced in #573604 (closed)). This limit is too short for teams whose operational or compliance cycles are weekly-based, where a 3-week (21-day) window would align better with sprint cadences and on-call rotations without requiring overly frequent token rotation.

Intended users

• Platform/infrastructure engineers managing runner fleets programmatically (e.g. BYOR services)
• Security teams enforcing token expiry policies aligned to sprint or on-call cycles
• Organizations with compliance requirements that map to 3-week windows rather than 2-week ones

User experience goal

Users should be able to set token_expires_at up to 21 days in the future when creating a runner token, giving them a full 3-week window before a token must be rotated or a new runner provisioned.

Proposal

Raise the MAXIMUM_TOKEN_EXPIRY_DURATION constant in app/services/ci/runners/create_runner_service.rb from 15.days to 21.days, and update the corresponding API documentation and validation error messages.

The effective maximum remains min(21 days, instance/group/project runner token expiration interval), so existing admin-configured limits are still respected.

Benefits

• Better alignment with 3-week sprint and on-call rotation cycles
• Reduces operational overhead for teams that currently have to work around the 15-day cap by re-creating runners more frequently than their process requires
• No security regression: the instance/group/project-level expiration interval settings continue to act as a hard ceiling

Permissions and security

No new permissions are required. The change only widens the upper bound of an existing validation. Admin-configured expiration intervals already cap the effective maximum, so administrators retain full control.

Documentation

• Update doc/api/users.md — "Create a runner linked to a user" — to reflect the new 21-day maximum for token_expires_at
• Update any validation error messages that reference "15 days"

Availability

Affects GitLab.com and Self-Managed equally.

Related

• #573604 (closed) — original feature that introduced token_expires_at with the 15-day cap (closed/shipped)