Add configurable API key expiration

[VibeSWE]

Description

API keys currently remain valid until deleted. Add an optional lifetime of 30 minutes through 90 days, or no expiration. For example, a collector key created with ttlSeconds: 1800 stops authenticating 30 minutes after creation through both X-API-KEY and Bearer headers.

• Persist a UTC expiresAt; omitted/null TTL preserves existing nonexpiring API behavior and legacy records.
• Enforce the deadline in authentication and key validation. Cap temporary sessions at the key deadline and prevent API-key session refresh, while preserving Basic-auth precedence for mixed headers.
• Default new UI-created keys to 90 days, with presets, custom minutes/hours/days, and an explicit No expiration option. Keep expired keys visible and deletable, and update their status automatically.
• Warn when an older backend ignores a requested finite lifetime. Preserve current role-based permissions and admin authority.

Rollout: upgrade every serving and metadata-writing node before creating expiring keys. Older versions ignore expiration and can strip expiresAt when rewriting metadata; rollback with finite keys in service is unsafe. Requests authorized before expiry may finish afterwards.

Review automation

Add the swamp post-pr-review workflow and comment-clanker-post model/script. Actionable findings use resolvable line or file review threads; parsed ordinary PR conversation comments are rejected by default. Review summaries and existing-thread replies are allowed, with allowConversationComments=true available for intentional general discussion. The wrapper validates the report before posting and revokes its repository-scoped App token afterwards.

Running the automation requires an initialized swamp repository, Node.js, gh-comment with typed review support, and the comment-clanker vault containing the App client ID and private key. Credentials and unrelated local automation are excluded from this PR. No review comments were posted during validation.

Validation: five policy tests, four installed-parser integration cases, Node syntax checks, and swamp model/workflow validation passed.

Validation

• Production frontend build and TypeScript pass; 2,200 unit tests pass across 89 files (one existing skipped test).
• 50 Chromium browser tests pass: 11 expiration regressions and 39 existing Team tests, including mobile accessibility.
• Final Rust build and 20 unique focused Rust tests pass.
• 49 live HTTP/persistence assertions pass against the final build on a disposable single-node server. Covers TTL bounds, invalid inputs, both authentication headers, validation, retained expired records and restart compatibility. Expiry was simulated by editing only temporary persisted metadata while the server was stopped; no real 30-minute wait or cluster upgrade test was performed.
• Formatting/diff checks pass. Three Opus 5.5 review rounds completed; final review approved with no actionable findings.

Details: frontend/docs/validation-review.md and frontend/docs/api-contracts.md. Implementation is also recorded in the project's shared Mayfly wiki under Team → API key expiration. Nothing deployed.

This PR has:

• been tested to ensure log ingestion and log query works (focused authentication checks passed; full ingestion/query smoke was not repeated).
• added comments explaining the "why" and intent where needed.
• added documentation for new or modified features and behaviors.

---

^{Need help on this PR? Tag @codesmith-bot with what you need.}

[comment-clanker]

Independent reviews by GPT-6.1-Sol (backend; frontend + automation) and Claude Opus 5.5 of commit 8acc2f6d9dde8e350d52beb34416c60c27786079, verified in a second Sol pass.

The core expiry enforcement looks correct. The API-key header lookup (find_api_key_user) and /apikeys/validate both call matches_active_key. Sessions created directly from API-key headers are capped at the key's deadline and excluded from refresh (the one exception is the first thread below). The ttlSeconds bounds are enforced at deserialization. expiresAt is serialized into persisted users and into cluster-sync payloads. No issues found in the frontend duration validation, the warning for backends that ignore the TTL, or the timer (capped at 2³¹−1 ms).

The reviewers reported passing runs of cargo check --locked --offline, 20 focused Rust tests, 147 frontend unit tests, 5 policy tests and the 11 expiration browser tests (these mock the server). No live cluster test was run.