Migrate FAB POST /roles to FastAPI

[chiuinggum]

Why

• Align FAB provider with Airflow 3’s FastAPI-first direction and reduce remaining Connexion/Flask surface. This PR is a small step for issue Replace connexion with fast-api for FAB provider. #56730 by migrating a single endpoint first.

How

• New FastAPI endpoint: implements POST /auth/fab/v1/roles using a router registered by FabAuthManager.get_fastapi_app(). Path and success status remain compatible (200 OK). The login FastAPI module serves as structural precedent.

• Data models: added Pydantic models in api_fastapi/datamodels/roles.py (RoleBody, RoleResponse, etc.). The JSON field actions is preserved via aliases while internal naming uses “permissions,” mirroring the Connexion schema.

• Service layer: api_fastapi/services/roles.py#create_role reproduces the legacy flow:

  1. validate role name
  2. conflict if role exists (409)
  3. validate action/resource pairs (422 on missing from Pydantic)
  4. bulk_sync_roles
  5. re-fetch or 500 on unexpected failure

• Authorization parity: introduced a FastAPI dependency that mirrors requires_access_custom_view("POST", RESOURCE_ROLE); unauthorized → 401, forbidden → 403 (same semantics as FAB’s Connexion layer)

• OpenAPI docs: response map includes 400/401/403/409 and now 500 for the rare “created-but-not-found” case, consistent with the new service behavior. (FastAPI auto-generates the schema from code.)

---

^ Add meaningful description above
Read the Pull Request Guidelines for more information.
In case of fundamental code changes, an Airflow Improvement Proposal (AIP) is needed.
In case of a new dependency, check compliance with the ASF 3rd Party License Policy.
In case of backwards incompatible changes please leave a note in a newsfragment file, named {pr_number}.significant.rst or {issue_number}.significant.rst, in airflow-core/newsfragments.

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

[vincbeck]

I like the direction!

[chiuinggum]

@vincbeck, thanks for the review! Will work on this tmr

[jason810496]

Thanks for the PR! LGTM overall.

[potiuk]

Love it :)

[chiuinggum]

Hi @jason810496 / @vincbeck / @potiuk, could you please take a look at this PR when you have a moment, thanks in advance!

[jason810496]

Nice!

[vincbeck]

Very good job!

[boring-cyborg]

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

[potiuk]

Fantastic :)