How to turn a string of silly mistakes into a mature positive outcome?

This is easier said than done, but don't worry too much about it and learn from them. From what I gather from your context, it doesn't seem like anybody is explicitly mad at you, and your tech lead is off to a great start asking you to write something formal for reflection to go through in the retro, an exercise that is entirely built to help teams learn and grow from past mistakes.

Something I really learned about at Meta is blameless culture. The idea is that when a mistake is made, the goal isn't to pin it to some person and attack them for it, it's to focus solely on learning from it instead.

Every team should follow blameless culture principles - It's better for team synergy and mental health, and it encourages people to share their mistakes instead of potentially hiding them and letting them fester (super dangerous with prod issues). You can be a champion of this culture by not feeling bad about your own mistakes, focusing that mental energy on learning instead, and being kind and understanding to others when they make mistakes.

How I can best approach owning this set of silly mistakes without it having a negative impact on my reputation due to my low code quality mistakes partly caused by the stress of the situation?

The best way is to show how extremely serious you are about learning from this situation - Make that retro write-up awesome and chock full of action items. Here are some ideas:

• More automated test coverage
• Adding more reviewers to your code reviews in the future
• Committing to more thorough context sections and test plans. Check out our code review masterclass for more details: [Masterclass] How To Do Amazing Code Review
• Adding more detailed monitoring, especially if you have a soak/beta channel before something goes all the way to production
• Using gradual rollout and kill switches (we did this for almost everything at Meta)

At the end of the day, this is the mentality to have:

1. I am comfortable with myself making whatever amount of mistakes I end up making.
2. I will never make the same mistake twice.

When you do that, you will grow at lightning speeds!

What's a "mini bug report"? Does it also include a retrospective of what happened, how it could have been avoided, and what safeguards you will take in the future to prevent it? In my opinion, a retrospective doc would help a lot in conveying the complexity of what you were working on, showing ownership of your mistakes, and demonstrating leadership and accountability by planning out and implementing the safeguard(s). Any reasonable manager would know that mistakes happen. If they have been in the industry for a while, they have seen their fair share of mistakes done by the smartest of engineers, and most likely they have been part of their fair share of mistakes too. It's what's done after the mistake that counts.

Something else I wanted to mention when it comes to blameless culture is that it's very much a phenomenon where you need to be the person you want others to be.

For a lot of folks, this empathy feels radical and unintuitive - I'm sure many people here have felt the judgment from adults when you accidentally broke something as a kid. This means that if you want your team to have blameless culture, it's extremely important that you champion the principle yourself and show deep kindness to your teammates when they mess up.

Some of these may feel a bit extreme as Meta was very big on blameless culture, but here's what I did when my teammates made mistakes, especially if they were my mentees:

1. Smile and tell them "Nice job!" - This was usually in a 1 on 1 setting but it wasn't too weird to hear this in a team setting either when it was a close group. This brevity really helps takes away the guilt the teammate naturally feels and really lets them know that mistakes are okay. Mistakes are crucial for learning, so this semi-encouragement actually makes sense.
2. Never focus on the "who" - It's all about the "what" (the code): It's not important at all who broke it, because anybody can have a bad day at any time and break any code. Ask questions like "What module broke?" and "What was the root cause?" instead of questions like "Who made the change?" or "How did [X person] not catch the issue in time?".
3. Use "we" to capture team spirit - Software is a team sport, and you're only as strong as your weakest link. The best teams are those that rise together and fall together, sharing both everyone's success and pain. When something breaks, the team's goal is to figure out how to emerge from it stronger than ever before by extracting the maximum learning. In post-mortems, you should ask questions like "How can we make this component more robust?" or "What can we do to catch issues more proactively?". The burden must be carried by all.