Function resolve_target_and_available_groups 

pub async fn resolve_target_and_available_groups(
    infra: &InfraContext<'_>,
    token: &str,
    settings_group_name_opt: Option<&str>,
) -> Result<(Vec<Group>, Vec<String>), Error>

Resolve the caller’s accessible groups (Vec<Group>) and the target-label vector in a single backend round-trip.

Three places in the service layer repeated the same three-call dance:

1. get_group_available to derive labels (used when no settings group is supplied).
2. validate_user_group_vec_access which itself called get_group_name_available to verify the labels.
3. A second get_group_available inside a try_join! to fetch the full Vec<Group> needed by the downstream filter.

All three steps want the same data; the helper folds them into one get_group_available call plus an in-memory check. Non-admin callers still get the same access-validation guarantee (they’re rejected with BadRequest if settings_group_name_opt names a group they can’t see); admin tokens short-circuit, matching the behaviour of crate::service::authorization::validate_user_group_vec_access.