## Problem `retrieval.spec.logicalRestore.options.configs` — a `map[string]string` of PostgreSQL GUCs applied during logical restore — is not part of the `ConfigProjection`. This causes two concrete problems: 1. **Invisible via API**: `GET /admin/config` never returns these settings even when present in the YAML config file. Users and support checking the API see no sign that restore-time GUCs are configured. 2. **Not editable via UI**: The configuration form has no fields for this section. Users must SSH to the host and edit `server.yml` directly, then restart the container — with no guidance that this is required. This caused real customer confusion: a user added the settings through the UI (which has no form fields for this), saw them in the YAML view, but concluded the config "wasn't picking it up" because `GET /admin/config` showed nothing. ## Why it matters The `configs` section under `logicalRestore.options` is the primary lever for speeding up logical restore of large databases. Recommended tuning for a 600 GiB database: ```yaml configs: maintenance_work_mem: 8GB max_parallel_maintenance_workers: 7 max_wal_size: 32GB checkpoint_timeout: 60min autovacuum: 'off' fsync: 'off' shared_preload_libraries: '' ``` Without UI/API support, users who need these settings have no self-service path. ## Solution Add `RestoreConfigs map[string]interface{}` to `ConfigProjection` with proj path `retrieval.spec.logicalRestore.options.configs`, and expose it as an editable textarea in the Configuration UI (same `key=value` per line format as the existing tuning params field). ## Acceptance criteria - `GET /admin/config` returns `restoreConfigs` when set - `POST /admin/config` accepts and persists `restoreConfigs` - UI Configuration page shows a "Restore PostgreSQL configs" textarea in the logicalRestore section - Tooltip explains purpose and gives examples (`maintenance_work_mem`, `fsync=off`, etc.) - Existing YAML-only configs are loaded into the form on page open (no data loss)