Standardize v2 connection-type (to-many) nested filters

Standardize how v2 filters express to-many (connection-type) nested relationships: filtering a parent entity by conditions on its related child collection.

Current state: nested relation filtering exists but is hand-rolled per entity. image->aliases (ImageConditions.by_alias_\*) and rbac role->user/scope (RoleConditions.by_assigned_user_id / by_mapped_scope) both use correlated sa.exists() subqueries with implicit SOME semantics, embedding a single {Relation}NestedFilter field. No explicit some/every/none quantifier exists anywhere, and there is no shared cross-entity EXISTS-builder abstraction.

Goal: define a documented convention (via BEP) for connection-type nested filters and apply it – first to DeploymentFilter.replicas (filter deployments by route/replica status/health/traffic), then to other pending connection filters.

The BEP (child 'Write BEP' task) decides: (1) filter shape – implicit-some single embed vs explicit some/every/none; (2) whether to introduce a reusable EXISTS-wrapper helper; (3) semantics documentation standard; (4) first application spec for DeploymentFilter.replicas.

Implementation stories are deferred until the BEP is accepted, then derived via /bep-to-issues.

Motivating analysis: v2 DeploymentFilter currently cannot filter deployments by whether they have operational replicas – the status filter only reflects deployment lifecycle (READY), not actual running/healthy/active routes. Precedent: BEP-1021 (GQL StringFilter Enhancement).

JIRA Issue: BA-6818

Start by reviewing the existing ImageConditions.by_alias_* and RoleConditions.by_assigned_user_id/by_mapped_scope patterns, then inspect DeploymentFilter.replicas and BEP-1021. The work is complete when the BEP documents the quantifier shape, EXISTS-wrapper decision, semantics standard, and initial DeploymentFilter.replicas application spec; implementation follows only after acceptance.

Written by the indexing model from the issue text.