fix(config): read client API keys from CPA v8 layout

[camy-x]

Summary

After CPA v8 moves client keys to access.api-keys, opening the visual configuration page shows an empty API Key list even though the keys still work. Read the effective v8 client-key field on initial load, while retaining older configurations and keeping upstream provider credential groups separate.

Scope

• Frontend panel
• Manager Server
• CPA panel mode
• Full Docker mode
• Native packages / release
• Docs / Wiki
• CI / build / tooling

Changes

• Give an explicitly present access.api-keys precedence, including empty lists and null; retain the legacy fallback when it is absent.
• Keep visual YAML serialization in the effective client-key location. Preserve the v8 root api-keys provider-group mapping and avoid reviving stale legacy keys when clearing client keys.
• Add hook coverage and page regressions using the real visual-config hook for initial load, dedicated create/replace/delete APIs, remounting, and unrelated configuration saves.

User Impact

Existing CPA v8 client keys appear immediately when opening or reloading Settings. Users no longer need to attempt a key mutation to populate the list.

Compatibility / Runtime Notes

• CPA panel mode: reads both legacy and v8 YAML layouts.
• Manager Server mode: same frontend parser; management proxy and backend remain unchanged.
• Full Docker / native packages: no packaging or runtime changes.
• API Key card mutations still use the existing dedicated /api-keys endpoints and canonical read-back. The YAML write change protects the hook's serialization path; normal card CRUD does not use that path.
• Scope is client API Key compatibility, not complete adaptation of every v8 visual setting.

Data / Security Notes

No database, authentication or secret-storage changes. Client keys cannot replace the top-level upstream credential groups. Fixtures and screenshots use synthetic keys only.

Risk / Rollback

Risk: low; limited to client-key YAML parsing/serialization. Revert this commit to restore previous behavior.

Verification

• Type check
• Lint
• Tests
• Build
• Manual UI check
• Docs/link check
• Not applicable, docs-only

Commands / evidence (from apps/web; invoked with the existing local Node binaries):

node ../../node_modules/typescript/bin/tsc --noEmit
node ../../node_modules/eslint/bin/eslint.js . --ext ts,tsx --report-unused-disable-directives
node ../../node_modules/vitest/vitest.mjs run src --maxWorkers=4
node ../../node_modules/vitest/vitest.mjs run src/hooks/useVisualConfig.test.ts src/features/config/ConfigPage.persistence.test.tsx src/services/api/apiKeys.test.ts
node ../../node_modules/vite/bin/vite.js build
git diff --check

• All 252 frontend test files / 4,168 tests passed; final focused run: 91 passed.
• Lint: zero errors; six pre-existing warnings in unchanged files.
• An initial unrestricted parallel run hit a 5-second timeout in an unrelated auth-store test; the full suite passed with four workers, without changing that test.
• New page regressions failed at initial v8 key loading before the fix.
• Browser check used the actual frontend with a local CPA-shaped HTTP fixture: initial display, add, edit, delete and reload worked; the upstream provider group remained unchanged. This is not a live CPA deployment acceptance test.
• Self-review and an independent review completed; v8 provider-group fixtures were corrected to the actual keys group structure before final focused verification.

Screenshots / Recordings

Initial display from v8 YAML, before any key mutation (synthetic keys):

Docs

• README / README_CN updated for user-visible capabilities
• Matching docs manual and navigation updated
• Demo fixtures, screenshots, and deep links reviewed
• Release notes needed
• Not needed — explanation included below

Docs decision: restores existing API Key behavior after an upstream layout change; no new controls or setup steps. A bug-fix release note is appropriate.

Related

Fixes #886. This is a necessary upstream compatibility fix within the 1.x maintenance scope described in #884.