Should we name names in a blameless post-mortem/retrospective?
Usually for a blameless postmortem, the best idea is to go further than the human error (which for a proper 5 whys should not arise, that's rule 11, but we're just humans :)) and complete the 5 Whys with the 5 Hows.

To follow on this particular case for a blameless postmortem I'd go few step further whith those iterations (For the sake of the example) of How possible follow up interpretation (possible answers):


How this fix has been left unmerged after creation ? (it wasn't reviewed and didn't follow the usual path)
How did it miss review ? (That was urgent and straightforward, review wasn't necessary and decision was taken to deploy)
How this process has been defined ? (It wasn't)
How was the bug report closed without merge (No validation/no defined process for this case)
How to prevent the problem arise again ? (Define the process and set validation/review even for quick patches)


Now you don't have someone who have forget to merge something, you have an analysis of how it was possible and more important, you have something actionnable to improve which is the main, if not the sole, reason to do a postmortem.

A more detailled criticism of the 5 whys (which as you show end often with a Who instead of a Why) can be found on O'reilly's blog post The infinite hows

To address the specific point of naming in the analysis, I'd argue neither the name nor the fix itself are of value, wording the step in the analysis as "An engineer wrote a fix and didn't merge it" without any link would be enough for the report.