Fix test_get_task_states_with_task_group_id_and_task_id to actually cover its name

[ColtenOuO]

Sumarry

test_get_task_states_with_task_group_id_and_task_id in airflow-core/tests/unit/api_fastapi/execution_api/versions/head/test_task_instances.py (TestGetTaskStates) is named to cover the case where GET /execution/task-instances/states is called with both task_group_id and task_ids set — the union-of-both-filters branch in get_task_instance_states (airflow-core/src/airflow/api_fastapi/execution_api/routes/task_instances.py):

if task_group_id:
    group_task_ids = _get_group_task_ids(dag_id, task_group_id, session, dag_bag)
    effective_task_ids = set(task_ids) | group_task_ids if task_ids else group_task_ids
    query = query.where(TI.task_id.in_(effective_task_ids))

The request built by the test only ever set task_group_id in params; task_ids was never passed. That makes the test identical in coverage to test_get_task_states_group_id_basic (which also only exercises task_group_id alone) -- the task_group_id | task_ids union branch was untested despite the test's name claiming otherwise.

Change

• test_get_task_states_with_task_group_id_and_task_id: added "task_ids": ["task2"] to the request params, alongside task_group_id="group1". task2 is a Dag-level task outside group1 in this test's Dag, and the fixture already assigns it a distinct state (FAILED), so the expected response now asserts both group1.task1 (from the task group) and task2 (from the explicit task_ids filter) appear together in task_states -- actually exercising the union path the test name describes.

[fat-catTW]

Awesome!!