Explicitly add pydantic dependency to http provider

[dabla]

As mentioned by @NBardelot, the HTTP provider now also has a direct dependency on Pydantic due to the addition of the SessionConfig class in the HTTP hooks module.

Although the pydantic dependency is currently resolved transitively through the airflow-core dependency, it is generally considered best practice to declare direct dependencies explicitly in the provider itself. Otherwise, the provider could break in the future if pydantic is removed from, or no longer exposed through airflow-core dependency tree.

---

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

• Yes (please specify the tool below)

---

• Read the Pull Request Guidelines for more information. Note: commit author/co-author name and email in commits become permanently public when merged.
• For fundamental code changes, an Airflow Improvement Proposal (AIP) is needed.
• When adding dependency, check compliance with the ASF 3rd Party License Policy.
• For significant user-facing changes create newsfragment: {pr_number}.significant.rst, in airflow-core/newsfragments. You can add this file in a follow-up commit after the PR is created so you know the PR number.

[Dev-iL]

No objection to this in general. One question though: which version does the provider actually needs to function? >=2.0.0? Most places that declare pydantic as a dep use 2.11.0, but apache-airflow-registry-tools uses 2.12.0 (where the latest is 2.13.x).

[dabla]

No objection to this in general. One question though: which version does the provider actually needs to function? >=2.0.0? Most places that declare pydantic as a dep use 2.11.0, but apache-airflow-registry-tools uses 2.12.0 (where the latest is 2.13.x).

2.11.0 should be fine for this case, I just need BaseModel, that's all.