Add OIDC worker token verification to Edge3

[robertpofuk]

Why

The Edge worker API currently only verifies worker tokens signed with the shared [api_auth] jwt_secret (symmetric HS512). This adds optional verification against a trusted OpenID Connect provider, so edge workers can authenticate with tokens minted by an external identity provider instead of the shared secret.

What

When [edge] oidc_jwks_url is set, worker tokens are verified against the provider JWKS using asymmetric signatures, checking the iss and (optionally) aud claims. New [edge] options:

• oidc_jwks_url — provider JWKS URL; enables OIDC verification when set
• oidc_issuer — expected iss claim
• oidc_audience — expected aud claim; leave empty to skip audience verification (for tokens that carry no aud)
• oidc_algorithms — accepted signing algorithms, comma-separated (default RS256)

When oidc_jwks_url is empty (the default), the existing shared-secret verification is used unchanged, so existing deployments are unaffected. The per-request signed method claim check is skipped in OIDC mode because externally issued tokens do not carry it.

Uses the existing core JWKS / JWTValidator; no new dependencies. Adds unit tests for validator selection, the config options, and the method-claim behavior (the module had no test module before).

Known limitation / follow-up

Some identity providers publish JWKS keys without an alg field. PyJWT then defaults such keys to RS256 and rejects tokens signed with another algorithm even when algorithms is passed to jwt.decode. That looks like it should be addressed in core JWTValidator rather than here, so it is intentionally out of scope for this PR. Happy to follow up separately if maintainers agree.

---

^ 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
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

[robertpofuk]

Tested on our internal environment by vendoring edge3 and re-building. Works nicely and makes our setup super simple since workers just order therir access via central IDP.

[robertpofuk]

Fixed CI failures and rebased on main.