feat(memory): generic ABC-driven Desktop config surface for memory providers

[erosika]

What this is

A generic, ABC-driven config surface for Desktop memory providers. Alternative direction to #37546 (Hindsight Desktop panel), addressing the per-provider-by-name concern raised in that PR's review.

The problem

Desktop has no per-provider memory config UI. #37546 added one for Hindsight, but the way it did it was per-plugin: a hardcoded memory_providers.py registry, a memory.provider === 'hindsight' conditional, and a dedicated endpoint pair. Adding mem0 next means copy-pasting another panel, another conditional, another endpoint — hand-maintaining N plugin pages.

The config abstraction already exists. Every MemoryProvider declares get_config_schema() + save_config() (used by hermes memory setup). The registry in #37546 re-declared config the providers already own — two sources of truth that drift.

What this does instead

Pushes the Desktop config surface onto the existing MemoryProvider ABC:

• Derive renderer metadata (label/kind/tier/options) from the schema providers already declare. Legacy schemas work untouched.
• read_config() default for the conventional layout; providers with non-conventional storage override it (Honcho routes through its own host-block resolution).
• One generic GET/PUT /api/memory/providers/{name}/config pair that delegates to the ABC. No per-provider branching, no registry.
• when conditional fields carried through generically — Hindsight's mode-gated fields are the worked example.

All 9 providers are supported via auto-derivation; no bespoke per-provider code.

Notable behavior

• Secrets are write-only: the value is never returned, only an is_set flag. A blank secret on save preserves the existing value.
• Saving a provider's settings does NOT change memory.provider. Activation stays a separate action.
• tier (safe/advanced) groups behavior-changing fields under a disclosure — editable, not locked (Desktop users may not use the CLI wizard).

Status

Backend + logic only. 375 tests green, 0 regressions. The React panel (generic renderer, dirty tracking, inline validation, when-aware rendering) and a cross-provider conformance test are still to come — opening as draft so the shared surface is reviewable first.

Test plan

pytest tests/agent/test_memory_config_surface.py \
       tests/hermes_cli/test_memory_provider_config_endpoints.py \
       tests/plugins/memory/test_hindsight_config_surface.py \
       tests/plugins/memory/honcho/test_honcho_config_surface.py

Refs #37546

[erosika]

Closing this. It solves the wrong layer.

The actual issue is that the desktop memory.provider dropdown is a hardcoded enum in constants.ts (['', 'builtin', 'honcho']), disconnected from discover_memory_providers() which the backend already runs. This PR built a generic config-panel/persistence framework on top of that dropdown without addressing the hardcoding — and #37546 just adds one more hardcoded entry plus a hand-built panel.

Replacing with a smaller change: wire the dropdown to discovery, drop the hardcoded enum. A config panel, if needed, is a separate follow-up scoped to providers that actually have UI-configurable settings.