A capability gate that derives config separately from the request builder drifts silently

Pattern: one function asks should I do this (checks AZURE_ENDPOINT and AZURE_KEY) while a different function actually builds the request (supports several providers via EMBEDDING_PROVIDER). Each is correct read alone. Switch providers and the gate never opens, so the background work silently never runs while the foreground path — which has no such gate — keeps working. Symptom was search returning {"results": []} with HTTP 200 forever, indistinguishable from an empty database. Fix was deriving the gate from the request builder (is_configured() defined next to the request function) so the two cannot diverge. Detection trick worth reusing: the bug was invisible in the app logs and obvious in the DOWNSTREAM service log — the embedding endpoint showed one inbound request per post-and-search where there should have been two. When a feature silently no-ops, count requests at the dependency, not at the caller.