feat[frontend](settings/api-key): added apikey on settings section

[AlexSanchez-bit]

No description provided.

[github-actions]

🛑 AI review — Sensitive area, extra care recommended

This PR touches critical paths or introduces changes the model cannot judge with sufficient confidence. Review carefully before merging.

✅ architecture (gemini-3-flash-lite) — clean

Summary: Refactored API keys management from a profile-embedded section to a dedicated top-level feature module.

No findings.

⚠️ bugs (gemini-3-flash-lite) — minor findings

Summary: Refactored API keys feature into a dedicated route; logic appears sound, but identified a potential UI/UX regression in the ConfirmDialog component.

• medium frontend/src/features/api-keys/components/ConfirmDialog.tsx:23 — The 'run' function in ConfirmDialog lacks a 'busy' state management, unlike the previous implementation in the deleted file. This allows users to trigger multiple concurrent API requests by clicking the confirm button repeatedly.

🛑 security (gemini-3-flash-lite) — high/critical — please review

Summary: Refactoring of API Key management from profile-embedded to a dedicated settings route; touches security-critical authentication/authorization paths.

• medium frontend/src/features/api-keys/pages/ApiKeysPage.tsx:77 — Hardcoded flag 'ENFORCE_ENTERPRISE_GATE = true' bypasses license checks for API Key management. Ensure this is intended for production or remove before merge.

🟢 go-deps — up to date

No pending Go dependency updates.

[AlexSanchez-bit]

click repetition (busy state) is handled on the shared confirm button already so there's no need to re implement it on api key confirm dialog (it uses shared confirm button underneath), moving api key management to a dedicated section is not a UI regression