feat: improve API key management flows

[MaxEriksson2000]

Summary

This PR groups the API key management work into focused commits:

• Refactors the API key frontend into lib/features/api-keys, including shared action menu, state badge, usage state, table helpers, moved dialog/components, read-only view-mode fixes, and a ticking rotation grace badge.
• Adds API key rotation grace policy support across backend models/routes/admin policy UI/schema, including fallback handling for rotation_grace_hours: null and a regression test for that case.
• Normalizes sk_ API key permissions so resource_permissions becomes the primary model for server keys while backend derives the effective top-level permission; pk_ keys remain excluded from fine-grained permissions.
• Adds an Alembic backfill for existing sk_ keys with resource_permissions IS NULL, preserving old simple-mode behavior by setting all resource types to the key's current permission.
• Fixes the service-key guardrail so derived write/admin resource permissions still require an IP allowlist or expiration, preventing permission=read from bypassing the guardrail.
• Tightens worker usage-stats behavior by removing the competing job-start path and asserting container tenant/user overrides are reset after queuing while queued params still carry context.
• Applies small UI/error polish for radio token usage and error code 9038.

Why

The API key management changes had grown across staged and unstaged frontend/backend edits. This keeps the ownership boundary clearer, reduces duplicated table/action code, avoids a rotation crash when policy explicitly sends null, makes view mode less misleading by disabling permission controls, and moves permission synchronization for sk_ keys into backend-owned security logic instead of relying on frontend-only calculations.