fix(memory): generic embedding/rerank provider listing + runtime fallback for all configured providers

[rqzbeh]

Problem

On dashboard/memory?tab=engine, the Embedding Model Quick select (and the Rerank selector) built their model lists only from a keyword heuristic over the CHAT catalog (AI_MODELS) plus OpenRouter live discovery. Providers whose embedding models are not in that catalog never appeared — even though many configured providers (mistral, gemini, nvidia nim, groq, vercel-ai-gateway, ...) serve embeddings on a standard OpenAI-compatible /embeddings endpoint — and typing such a model manually failed at runtime with "Unknown embedding provider".

Fix — one generic mechanism, no per-provider patches

• Registry derivation (embeddingRegistry.ts): deriveEmbeddingProviderForChatProvider() turns ANY chat-registry entry with a /chat/completions base into an OpenAI-compatible /embeddings config. Curated EMBEDDING_PROVIDERS entries always win.
• Runtime fallback: embeddings service resolves a derived config for unknown-but-configured providers instead of rejecting them; same for rerank via deriveRerankProviderForChatProvider() (Cohere-compatible /rerank).
• Listings merge: Quick-select catalog merges curated registry models; listEmbeddingProviders() appends every CONFIGURED derivable provider (credential check) with an empty model catalog; new /api/memory/rerank-providers serves the rerank listing separately.
• UI: both memory selectors fall back to a free-text provider/model input when no static models exist.

No provider is registered or special-cased by name — adding a provider to the chat registry automatically makes it embedding/rerank-capable here.

Validation

TDD: 5 new test files + 2 focused additions:

• tests/unit/qdrant-quick-select-catalog.test.ts, tests/unit/memory-provider-listings.test.ts, tests/unit/rerank-provider-listings.test.ts, tests/unit/embedding-generic-provider-fallback.test.ts, tests/unit/rerank-generic-provider-fallback.test.ts, plus cases in tests/unit/embeddings-handler.test.ts

Results: focused suites 32/32 pass; wider embed/memory/rerank/qdrant suites 0 fail; npm run typecheck:core clean; ESLint clean on all changed files (4 pre-existing unused-var warnings on untouched base lines excluded).

Rebased on release/v3.8.50.

---

⚠️ base-red inherited: #9985 — two remaining check failures are inherited from release/v3.8.50 itself, not from this branch (verified byte-identical on base, absent from this diff):

• No new ESLint warnings: unsuppressed @typescript-eslint/no-unused-vars (formatVideoTimestamp) in src/lib/guardrails/videoBridge.ts — file untouched here; error present on base tip with no suppression entry.
• Fast Quality Gates (file-size): tests/unit/guardrails/videoBridgeResultCache.test.ts 1040 > cap 1000 — file untouched here, identical on base-ref and base tip.
  Per repo policy these belong to the freeze-gated basereds campaign, not this feature PR.

[diegosouzapw]

Re-homed to release/v3.8.51: v3.8.50 entered its release freeze, so the branch now belongs to the release captain and development continues on the next cycle. Nothing is wrong with this PR — it just needed a live base. No action needed from you; CI will re-run against the new base.

[diegosouzapw]

Nice mechanism — curated-entries-win derivation with credential-gated listings is the right shape, and all five of your new suites pass on the branch as pushed. Main blocker: the branch was synced against the release/v3.8.50 lineage, so the PR currently drags ~44 unrelated commits toward release/v3.8.51. Please re-derive from the current release/v3.8.51 tip and rebase your two commits there (expect small conflicts in the memory/embedding files and EngineTab). Also note our active base-red tracking moved to issue #11449 — re-check your CI exceptions against it after the rebase.