Enable false_positive Execution Fallback for Vulnerabilities Search

Problem

The vulnerabilities search pipeline is currently tightly coupled to Elasticsearch readiness.
Any new filter (such as false_positive) must wait for:

• Elasticsearch schema changes
• Elasticsearch migrations
• Backfill completion

before it can be safely used by the frontend. This blocks frontend delivery, wastes milestones, and prevents parallel development.

In addition, the meaning of false positive has evolved. It is no longer derived from confidence score, but from an explicit domain state:

status = detected_as_fp

Postgres queries, preloaders, and enrichments must reflect this new semantics consistently.

Without execution fallback:

• Frontend filters cannot be shipped early
• Mixed-version compatibility is fragile
• PG and ES can disagree on filter meaning
• ES migrations become a hard release dependency

Solution

Introduce false_positive as an execution fallback filter using the new detected_as_fp semantics.

This change:

• Implements a PG-backed enrichment for false_positive
• Wires it into the execution fallback framework
• Guards it behind a feature flag
• Automatically disables fallback once Elasticsearch becomes authoritative
• Aligns all queries with the new domain definition of false positives

This change enables:

• Frontend parallelisation
  UI can ship false_positive filtering before Elasticsearch is ready.

• Multi-version compatibility
  Older backends safely ignore unsupported filters.
  Newer backends fall back to PostgreSQL transparently.

• Migration safety
  Elasticsearch becomes authoritative only when ready, without breaking clients.

• Semantic correctness
  false_positive now strictly means:
  “Has a false positive flag whose status is detected_as_fp.”