[security] Config file (which may hold model-backend apiKeys and other credentials) written with default world-readable permissions

**Severity:** MEDIUM · **Category:** `insecure-file-permissions` · **CWE-276**
**Location:** `config/configUtils.ts:105` in `atomicWriteFile`

## Impact
Any unprivileged local user or process on the host can read secrets (model backend API keys, and any other credential an operator places inline in config) from the world-readable harperdb-config.yaml and its accumulated .bak copies.

## Details
harperdb-config.yaml can carry inline credentials (e.g. component/model backend apiKey values, per resources/models/backendHelpers.ts requireCredential, which accepts a literal non-placeholder secret) and this write creates the temp file with fs-extra's default mode (0o666 & umask -> typically 0o644); the subsequent renameSync preserves that mode, and no chmod is ever applied to the config or its backups, leaving credentials readable by every local user.

## Exploit scenario
An operator sets a model backend apiKey via SET_CONFIGURATION or the install args; updateConfigValue -> atomicWriteFile writes it to harperdb-config.yaml with mode 0o644. A co-tenant local account or a low-privilege service on the same machine reads the file and exfiltrates the API key.

## Preconditions
- A credential (e.g. model backend apiKey) is stored inline in the config rather than only as an unresolved ${VAR} placeholder
- Host has other local users/processes (multi-tenant or shared box) and a permissive umask (022)

## Recommended fix
Create the temp file and set the final config file (and its backups) to owner-only permissions (e.g. write with { mode: 0o600 } and fs.chmodSync after rename); avoid persisting resolved secret values to the YAML at all, keeping only ${VAR} references.

---
Found by an automated multi-agent security review (Claude Security) against `origin/main` @ `2615b092b`, confirmed by a three-lens verification panel. Line numbers are as of that commit. No code was executed; derived from source review, so validate before remediation.

Start in config/configUtils.ts:105 at atomicWriteFile, then trace updateConfigValue and how harperdb-config.yaml and its .bak copies are written. Verify the temporary file, final config, and backups are owner-readable only, and check whether resolved credential values can remain out of the YAML instead of being persisted.

Written by the indexing model from the issue text.