docs(edge3): clarify WorkerQueuesBase.team_name is an experimental hint, cross-ref workload.rst

[omkhar]

The current WorkerQueuesBase.team_name field description implies the field provides team isolation when set. workload.rst documents the actual contract: [core] multi_team is experimental, and the Execution API does not enforce team boundaries today. This PR aligns the field description with that documented stance so operators reading only the API datamodel see the same caveats workload.rst already states.

No behavior change. No new APIs. Docs / docstring only.

Before:

Team name for multi-team setups. If not provided, worker operates without team isolation.

After:

Team name for the experimental ``[core] multi_team`` feature. This is a UI/REST API-level hint; the Execution API does not currently enforce team-based access boundaries -- see ``airflow-core/docs/security/workload.rst`` (section: 'No team-level isolation in Execution API'). Workers without team_name behave as default-team workers.

Cross-reference: airflow-core/docs/security/workload.rst section "No team-level isolation in Execution API (experimental multi-team feature)".

[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
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: dev@airflow.apache.org
  Slack: https://s.apache.org/airflow-slack

[jscheffl]

I asusme some static checkf ails as generated FastAPI spec is not updated. Please fix.

No real harm to change api docs but usually they are not read by humands and are just for code generators. So not surewhat this would improve... but as also no harm OK for merge in my view.

[jscheffl]

If you want to be really consistent, please add the same note also to CLI --help and to other places where CLI is mentioned in docs.

[jscheffl]

@omkhar ping - some static checks fail, please use prek to re-generate fast-api bindings. Then CI will turn green most probably.

[potiuk]

@omkhar A few things need addressing before review — see our Pull Request quality criteria.

Issues found:

• ❌ Pre-commit / static checks: CI image checks / Static checks is failing. Run prek run --from-ref main --stage pre-commit locally and fix anything that flags. See the static-checks docs.

What to do next:

• Push a fix for the static-check failure.

No rush — take your time. We appreciate your contribution and are happy to wait for updates. If you have questions, feel free to ask on the Airflow Slack.

---

Note: This comment was drafted by an AI-assisted triage tool and may contain mistakes. Once you have addressed the points above, an Apache Airflow maintainer — a real person — will take the next look at your PR. We use this two-stage triage process so that our maintainers' limited time is spent where it matters most: the conversation with you.

[omkhar]

Apologies for the delay — back at it.

Just pushed two commits:

1. 3eaed3f01 — regenerated the FastAPI bindings via prek (the static-check delta you flagged, Jens). Diff is confined to three description: updates in v2-edge-generated.yaml mirroring the docstring.
2. f7508a8f0 — extended the same experimental-hint note to airflow edge worker --team-name --help, providers/edge3/docs/deployment.rst, and the multi-team section of providers/edge3/docs/edge_executor.rst. Wording matches PR-A's docstring, with a :doc:apache-airflow:security/workload cross-reference. Happy to split into a sibling PR if you'd rather keep docs(edge3): clarify WorkerQueuesBase.team_name is an experimental hint, cross-ref workload.rst #66718 docstring-only, Jens — let me know.

The workflow runs are in `action_required` state (first-time contributor gate) — would appreciate a maintainer approval click when convenient.

Thanks for the patience.

[boring-cyborg]

Awesome work, congrats on your first merged pull request! You are invited to check our Issue Tracker for additional contributions.