Copy 2.11.2 release notes to main

[potiuk]

The 2.11.2 release notes were written on the 2.11 branch but never copied to
main, the way #62271 did for
2.11.1. RELEASE_NOTES.rst therefore jumps straight from 2.11.1 (2026-02-20) to
Airflow 3.0, and every release-notes page built from main since inherits the
gap — including the 3.2.2 and 3.3.0 docs, both published well after 2.11.2
shipped on 2026-03-11.

This copies the 2.11.2 section verbatim from the 2.11.2 tag and drops it in
front of 2.11.1, keeping the file's series-then-reverse-chronological order.
reproducible_build.yaml is updated by the update-reproducible-source-date-epoch
hook, same as the 2.11.1 copy.

The already-published 3.2.2 and 3.3.0 doc archives stay as they are — those
pages are frozen at their release builds, so restoring 2.11.2 there needs a docs
republish from the corresponding release branches, which is a release-manager
action rather than something this PR can do.

closes: #69882

---

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

• Yes — Claude Code (Opus 5)

Generated-by: Claude Code (Opus 5) following the guidelines

[github-actions]

Hi maintainer, this PR was merged without a milestone set.
We've automatically set the milestone to Airflow 3.3.2 based on: backport label targeting v3-3-test
If this milestone is not correct, please update it to the appropriate milestone.

This comment was generated by Milestone Tag Assistant.

[github-actions]

Backport failed to create: v3-3-test. View the failure log Run details

Note: As of Merging PRs targeted for Airflow 3.X
the committer who merges the PR is responsible for backporting the PRs that are bug fixes (generally speaking) to the maintenance branches.

In matter of doubt please ask in #release-management Slack channel.

Status	Branch	Result
❌	v3-3-test

You can attempt to backport this manually by running:

cherry_picker ea7f1cf v3-3-test

This should apply the commit to the v3-3-test branch and leave the commit in conflict state marking
the files that need manual conflict resolution.

After you have resolved the conflicts, you can continue the backport process by running:

cherry_picker --continue

If you don't have cherry-picker installed, see the installation guide.