Prepare 2.4.1

[jakelishman]

AI/LLM disclosure

• I didn't use LLM tooling, or only used it privately.
• I used the following tool to help write this PR description:
• I used the following tool to generate or modify code:

We need to decide if we're going to finalise the backport #16077 as well - if so, that should merge before this.

[qiskit-bot]

One or more of the following people are relevant to this code:

• @Qiskit/terra-core

[mtreinish]

Should we update the qpy version table too?

[jakelishman]

This QPY version-table update story is awkward, because the decision to release a new version is triggered by a patch directly on the stable branch, but the table would need updating on main. It feels awkward to have to do that via the backport process (whether backporting from main to here, from here to main, or two separate manual PRs) - we should probably come up with another way of managing this (and at least add it to the maintaining guide).

Doen in edaad51 for now.

[mtreinish]

Yeah, I only brought it up because we're preparing the release now. So we'll need to forward port that change to main. If things were not on a compressed timetable I'd push another docs PR like #16034. I agree we probably want a better story around this. We could implement something like what I did for the qiskit metapackage version table. It seems a bit heavyweight to write a custom sphinx plugin to check the source tree at different versions to pull the version attributes out. Especially since it would complicate the build process by needing git installed (although we could use dulwich like reno does). It might be the best solution to avoid the manual update step though.