On the presumption that the software defect in production was not due to intentional obscuration of the defective code, an apology email or message about the defect is unnecessary unless root cause analysis finds only you at fault through the root cause of the issue.
Ultimately, your team's review process and the testing you did was part of the process to try and avoid defects in the future, and that is the aspect being reviewed because it failed to catch a bug in production before it went live, and led to the team discovering it after the fact, and rolling back to a previous version.
I'm not sure of the nature of the Root Cause Analysis meetings you're in, whether your team is accepting blame for the failing of other team's downstream products as a result of your change, or if they're trying to figure out if the issue was upstream of your team and something your team needs to be aware of.
It sounds like it might be the former, given this:
I feel embarrassed for not recognising the issue in my code well in time and causing a lot of hassle for my team. However, fixing the issue and our process around deployments to ensure this does not happen again, has been a great learning experience for me as an engineer.
But if it was the latter, you're effectively doing the job of ensuring that their code is better, or that your team has a better understanding of the upstream code that your team is using - which is a defect that was being investigated to avoid other teams downstream of them from having a similar defect.
This all said, in either case, the question I have is: "How long after the issue was discovered that the cause of the defect was discovered and fixed?" It sounds like it's been about a week, or potentially less than that - it's only just Wednesday here, which means, if it was deployed on Friday, your team learned of the issue on Monday, and solved it by Wednesday.
That's pretty quick turnaround, especially given meetings, for tracking and resolving the issue.
Let me introduce you to the concept of Code Golf.
The concept of Code Golf in the questions linked to above is to, given a problem space, solve it in the least number of bytes. Given the language used in some of these cases, their code is intentionally more vague specifically to save bytes of filesize information.
One potential use of something like that is to obscure the goal of the software, and in doing so, would allow you to get something like these problem space solutions into areas they shouldn't necessarily be.
If your initial solution that led to the defect in your code was due to intentionally making it hard to catch the issue, and making them spend more time isolating what specifically went wrong, you very much probably should apologize to your team for making it into an almost "Gotcha" territory defect. Given how you've phrased it as a mistake that you yourself missed, that doesn't seem to be the case - and the quick turnaround on catching it means that the issue was easier to spot than some more difficult bugs.
It didn't get caught on the spot, or before it made it to production, but catching the initial reason for the defect was relatively easy to do after the team was alerted to it, despite the time pressure to find it. The resulting meetings afterwards were related to how to avoid causing that defect, but the issue was about the defect itself, not on how the defect managed to stick around for multiple releases due to being a hard to find defect in a messy codebase, nor one that intentionally meant to mislead others to approve it.
TL:DR; You'd apologize if you had something like a non-standard use of GOTO to achieve obscure ways of bypassing Dev and QA testing environments intentionally for an issue to land in production, but if that's not the case, you should be fine - everyone makes mistakes that make it to production before being found at least once.