Adopt flit 4 as the provider distribution build backend

[potiuk]

flit build has no PEP 517 build isolation — flit/wheel.py does import flit_core.wheel as core_wheel, so the backend is whichever flit_core is installed. That makes the flit_core== pin every provider declares inert on the path we release from, and leaves breeze's own dependency as the only thing deciding it. The specifiers were capped below 4 so that backend could not change by accident; this takes the cap off deliberately.

Validation

Built apache-airflow-providers-imap with 3.12.0 and with 4.0.2, same SOURCE_DATE_EPOCH, --use-vcs passed explicitly in both:

• wheel members identical — 13 files
• sdist members identical — 33 entries
• METADATA differs only by the intended additions:

-Metadata-Version: 2.4
+Metadata-Version: 2.5
+Import-Name: airflow.providers.imap
+Import-Namespace: airflow
+Import-Namespace: airflow.providers

The metadata parses cleanly, so the 4.0.1 defect that cost METADATA its header/body separator is confirmed fixed in 4.0.2.

Floors, not bumped caps

The issue notes the hazard: upgrade_important_versions.py rewrites these by version number, so bumping flit>=3.12.0,<4 would have produced flit>=4.0.2,<4. flit, flit-core and the 104 per-provider flit_core== pins now all move together at 4.0.2, and the tracking comment at the cap site is removed.

One addition the issue does not mention

flit 4.0.2 was published 2026-08-04, inside the "4 days" exclude-newer window, so uv refuses it and the adoption would not take effect. A temporary per-package cutoff is added in both [tool.uv.exclude-newer-package] and [tool.uv.pip.exclude-newer-package], following the existing pydantic-ai-skills precedent, with a note to remove it once the rolling window advances past 2026-08-04.

closes: #71121

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

• Yes — Claude Opus 5 (1M context)

Generated-by: Claude Opus 5 (1M context) following the guidelines