Fix execution API token access checks

[Vamsi-klu]

Fix execution API token access checks for connections, variables, and XComs by requiring a valid TaskInstance and tightening XCom read/write rules. Also refreshes a small doc note and removes stale TODOs.

Issue

• Execution API access checks for connections/variables/XComs did not verify that the JWT token maps to an existing TaskInstance, so a token with a non-existent TI id could pass the guard.
• XCom access rules were permissive: read access did not require a matching DAG for the token's task instance, and write access did not require a full DAG/run/task match.
• Tests did not cover missing TaskInstance tokens or mismatched XCom read/write scenarios.

Solution

• Validate the TaskInstance for each request token and fail fast with a 403 if the TI does not exist.
• Enforce XCom read access to the same DAG as the token's TaskInstance, and write access to the same DAG/run/task tuple.
• Extend tests to exercise missing TI tokens and XCom cross-DAG/write mismatches.

Implementation details

• Added a shared helper to resolve TaskInstance from token claims and centralize the 403 error shape.
• Routed connection/variable access checks through the new helper to ensure the token always maps to a real TI.
• Tightened XCom access checks to distinguish read vs write and enforce the correct scope for each.
• Updated test auth fixtures so tests can pass real TaskInstance ids through the Authorization header.
• Updated the local virtualenv docs to be explicit that uv sync --all-packages is required when running airflow-core tests that still touch provider deps.

Low-level changes

• airflow-core/src/airflow/api_fastapi/execution_api/deps.py: add get_task_instance_from_token and reuse it in access checks.
• airflow-core/src/airflow/api_fastapi/execution_api/routes/xcoms.py: enforce TI-based read/write restrictions and log using ti.id.
• airflow-core/src/airflow/api_fastapi/execution_api/routes/variables.py: validate TI presence before variable access.
• airflow-core/src/airflow/api_fastapi/execution_api/routes/connections.py: validate TI presence before connection access.
• airflow-core/tests/unit/api_fastapi/execution_api/conftest.py: add auth_headers fixture and token parsing logic in the JWT validator mock.
• airflow-core/tests/unit/api_fastapi/execution_api/versions/head/test_connections.py: add missing-TI denial test and use auth headers for existing coverage.
• airflow-core/tests/unit/api_fastapi/execution_api/versions/head/test_variables.py: add missing-TI denial test and update access-denied override to call the real guard.
• airflow-core/tests/unit/api_fastapi/execution_api/versions/head/test_xcoms.py: add read/write denial tests and route auth through TI tokens.
• airflow-core/src/airflow/api_fastapi/common/db/common.py: clarify that permission filtering happens via route-level filters.
• airflow-core/src/airflow/api_fastapi/execution_api/routes/assets.py: remove stale JWT TODO comment.
• airflow-core/src/airflow/api_fastapi/execution_api/routes/asset_events.py: remove stale JWT TODO comment.
• contributing-docs/07_local_virtualenv.rst: clarify uv sync --all-packages requirement (remove TODO).

Impact

• Execution API now rejects tokens that do not map to an existing TaskInstance for connections, variables, and XComs.
• XCom access is scoped to the TaskInstance's DAG for reads and to DAG/run/task for writes, reducing cross-DAG access risks.
• Expanded tests cover the new access checks and denial paths; doc guidance is clearer for local dev setup.

Tests

• PATH=$PWD/.venv/bin:$PATH UV_CACHE_DIR=$PWD/.cache/uv AIRFLOW_HOME=$PWD/.airflow .venv/bin/pytest -p no:rerunfailures airflow-core/tests/unit/api_fastapi/execution_api/versions/head
• PATH=$PWD/.venv/bin:$PATH ~/.local/bin/breeze testing core-tests --backend mysql --db-reset airflow-core/tests/unit/api_fastapi/execution_api/versions/head/test_task_instances.py::TestTIUpdateState::test_ti_update_state_reschedule_mysql_limit

Suggested reviewers

• @ephraimbuddy @pierrejeambrun @rawwar @jason810496 @bugraoz93 @shubhamraj-git @choo121600
• @ashb @kaxil @amoghrajesh

Was generative AI tooling used to co-author this PR?

• Yes (OpenAI Codex / GPT-5)

Generated-by: OpenAI Codex following https://github.com/apache/airflow/blob/main/contributing-docs/05_pull_requests.rst#gen-ai-assisted-contributions

[boring-cyborg]

Congratulations on your first Pull Request and welcome to the Apache Airflow community! If you have any issues or are unsure about any anything please check our Contributors' Guide (https://github.com/apache/airflow/blob/main/contributing-docs/README.rst)
Here are some useful points:

• Pay attention to the quality of your code (ruff, mypy and type annotations). Our prek-hooks will help you with that.
• In case of a new feature add useful documentation (in docstrings or in docs/ directory). Adding a new operator? Check this short guide Consider adding an example DAG that shows how users should use it.
• Consider using Breeze environment for testing locally, it's a heavy docker but it ships with a working Airflow and a lot of integrations.
• Be patient and persistent. It might take some time to get a review or get the final approval from Committers.
• Please follow ASF Code of Conduct for all communication including (but not limited to) comments on Pull Requests, Mailing list and Slack.
• Be sure to read the Airflow Coding style.
• Always keep your Pull Requests rebased, otherwise your build might fail due to changes not related to your commits.
  Apache Airflow is a community-driven project and together we are making it better 🚀.
  In case of doubts contact the developers at:
  Mailing List: [email protected]
  Slack: https://s.apache.org/airflow-slack