Filtered Aliases (Alias + Default Query Filter)

Is your feature request related to a problem? Please describe.
Qdrant aliases are limited to:

alias -> collection

In multi-tenant or logically partitioned applications, we often need every query against a collection to include the same payload filter (for example tenant_id, environment).

Right now this filtering must be implemented manually in application code for every request. This creates:

• repeated boilerplate
• higher risk of accidentally omitting required filters (from a sysadmin point of view)
• bespoke service layer in front of qdrant taking care of these concerns

This becomes especially noticeable when using a single large shared collection for many tenants or logical namespaces, not to forget there is a limit on # of collections in qdrant.

Describe the solution you'd like
It would be useful if aliases could optionally include a persistent/default filter, similar to Elasticsearch filtered aliases.

{
  "create_alias": {
    "collection_name": "documents",
    "alias_name": "tenant_a_docs",
    "filter": {
      "must": [
        {
          "key": "tenant_id",
          "match": {
            "value": "tenant_a"
          }
        }
      ]
    }
  }
}

Then queries against:

tenant_a_docs

would automatically apply the alias filter.

If a request also includes its own filter, the effective filter could be:

alias_filter AND request_filter

This would allow aliases to behave more like logical scoped views over collections.

Describe alternatives you've considered

• The current alternative is enforcing filters entirely in application code.
• We create a bespoke service layer just to enforce this logical separation.

Additional context

• This is similar to elasticsearch aliases
• It's unclear if we must support the write path to auto-inject mandatory fields to the payload

Start by reviewing how aliases are represented and how query filters are applied, then compare the requested behavior with the existing alias and filter APIs. Done would require a decided scope for read filtering and whether writes must inject fields, followed by implementation and tests for combining alias and request filters.