Not quite. It merges the MR HEAD commit into the target branch, any backport branch gets the same. So you get a graph that looks like this:
-- M - M - M (master)
/ /
T /
/ \ /
-- R - R (release)
Where T is merged independently into master and release. As part of making release always reachable from master, there is then a git merge -s ours release done on master. This is then pushed all-as-one to the main repository using git push --atomic.
Note that T might be different for each backport target branch from a single MR (e.g., Backport: release:HEAD^2) which is why, in general, separate merges are necessary (rather than merging once then cascading the branches together via merges that way).
Various branch/MR topologies for different situations: https://gitlab.kitware.com/utils/git-workflow/-/wikis/Backport-topics
Implementation of the logic to do the backports: https://gitlab.kitware.com/utils/rust-ghostflow/-/tree/master/ghostflow%2Fsrc%2Factions%2Fmerge