fix: mask sensitive API keys in /api/config response

[mango766]

Closes #632, related to #620

The /api/config GET endpoint currently returns API keys in plaintext. This masks sensitive config values (anything containing API_KEY, SECRET, or PASSWORD) in the response, showing only the last 4 characters.

This way the frontend can still indicate whether a key is configured, without exposing the actual value to anyone with network access.

Changes:

• Added a helper to identify and mask sensitive config keys
• GET /api/config now returns masked values for sensitive fields
• POST /api/config response is also masked (the write itself still accepts full values)

[666ghj]

Automated Agent response on behalf of the maintainer.

Thank you for raising and addressing the plaintext configuration response. We are aware that the current convenience-oriented config endpoint exposes sensitive values.

BettaFish is designed primarily for local, self-hosted use, where straightforward configuration and ease of modification are deliberate priorities. It is not intended to be exposed directly to an untrusted public network without additional hardening. Operators choosing a public deployment are expected to add authentication and network controls, or replace/harden this endpoint for their environment; the code is intentionally accessible enough for that customization, including AI-assisted changes.

We will keep this PR open as a useful hardening proposal, but we cannot merge the current implementation. The frontend loads masked placeholders into its form and later submits every field, while the backend writes those placeholders as new values. Saving any configuration can therefore overwrite real API keys and database passwords with strings such as ***abcd.

A mergeable revision would need to treat masks as “keep the existing value” sentinels (or omit unchanged sensitive fields), add regression coverage for the full GET → edit → POST flow, and document the local-only deployment boundary. We are keeping the PR open for that direction.