# Problem Statement The `VulnerabilitiesResolver` is currently tightly coupled to direct Elasticsearch execution. This means any new filter that is not yet supported by ES blocks frontend delivery or forces risky, one-off workarounds. There is no safe integration point to prepare the resolver for fallback-based execution. Without wiring the resolver into the fallback pipeline: - Frontend and backend remain sequentially coupled - ES migrations become all-or-nothing - Multi-version compatibility is harder to guarantee - Introducing fallback filters later becomes more invasive ### Solution Route `VulnerabilitiesResolver` through the execution fallback pipeline by: - Wrapping its execution with `ExecutionFallback::VulnerabilitiesResolver.fetch_with_filter_fallback` - Introducing a resolver-specific fallback class that: - Defines a safe result cap (`RESULT_MAX_RECORDS`) - Defines a standard overfetch window - Wires an enrichment namespace - Provides a unified fallback configuration entry point - Adding a dedicated vulnerabilities enrichment namespace - Adding specs to verify: - Delegation from the GraphQL resolver - Correct pagination bounds - Correct enrichment wiring No fallback filters are enabled yet. Behaviour remains unchanged, but the resolver becomes fully fallback-ready. This is a structural change that prepares vulnerabilities search for: - Parallel frontend/backend development - Multi-version compatibility - Safe, incremental ES -> PG filter migrations - Future fallback filter enablement behind feature flags