Configurable expiration (TTL) for personal and organization auth tokens

### Problem Statement

Auth tokens (personal auth tokens and organization auth tokens) never expire. The only way to rotate one is to manually create a new token and revoke the old one. There's no way to set an expiration or TTL, so a token that isn't manually revoked stays valid indefinitely. This makes it hard for teams to enforce a key-rotation/governance policy (for example 30/60/90-day rotation) for tokens used in CI and automation: even with a policy in place, nothing forces an un-rotated token to expire, so a forgotten token remains live forever.

### Solution Brainstorm

Allow an optional expiration (TTL) to be set when creating an auth token (personal and organization), after which the token automatically expires and must be replaced. Ideally notify the token owner and/or org owners ahead of expiry so rotation can happen without breaking pipelines. The token model already tracks an expires_at and enforces expiry for OAuth tokens, so this would extend existing behavior to user and org auth tokens rather than introduce a new mechanism.

### Product Area

Settings - Auth

Start in the Settings - Auth area and trace how personal and organization auth tokens are created and validated. Read the token model's existing expires_at handling for OAuth tokens, then compare the current user and organization token flows. Done means optional TTL-based expiry works for both token types, with the proposed expiry notifications addressed or explicitly scoped.

Written by the indexing model from the issue text.