Unfortunately, this rendering is technically correct. For example, the relevant Trac-rendered HTML in the HscMain page looks like this:
<ul><li>The <strong>Front End</strong> processes the program in the <aclass="wiki"href="/trac/ghc/wiki/Commentary/Compiler/HsSynType">big HsSyn type</a>. <code>HsSyn</code> is parameterised over the types of the term variables it contains. The first three passes (the front end) of the compiler work like this:<br/><br/><ul><li>The <strong><aclass="wiki"href="/trac/ghc/wiki/Commentary/Compiler/Parser">Parser</a></strong> produces <code>HsSyn</code> parameterised by <strong><aclass="wiki"href="/trac/ghc/wiki/Commentary/Compiler/RdrNameType">RdrName</a></strong>. To a first approximation, a <code>RdrName</code> is just a string. (<code>-ddump-parsed</code>) <br/><br/></li><li>The <strong><aclass="wiki"href="/trac/ghc/wiki/Commentary/Compiler/Renamer">Renamer</a></strong> transforms this to <code>HsSyn</code> parameterised by <strong><aclass="wiki"href="/trac/ghc/wiki/Commentary/Compiler/NameType">Name</a></strong>. To a first appoximation, a <code>Name</code> is a string plus a <code>Unique</code> (number) that uniquely identifies it. In particular, the renamer associates each identifier with its binding instance and ensures that all occurrences which associate to the same binding instance share a single <code>Unique</code>. (<code>-ddump-rn</code>) <br/><br/></li><li>The <strong><aclass="wiki"href="/trac/ghc/wiki/Commentary/Compiler/TypeChecker">Typechecker</a></strong> transforms this further, to <code>HsSyn</code> parameterised by <strong><aclass="wiki"href="/trac/ghc/wiki/Commentary/Compiler/EntityTypes">Id</a></strong>. To a first approximation, an <code>Id</code> is a <code>Name</code> plus a type. In addition, the type-checker converts class declarations to <code>Class</code>es, and type declarations to <code>TyCon</code>s and <code>DataCon</code>s. And of course, the type-checker deals in <code>Type</code>s and <code>TyVar</code>s. The <aclass="wiki"href="/trac/ghc/wiki/Commentary/Compiler/EntityTypes">data types for these entities</a> (<code>Type</code>, <code>TyCon</code>, <code>Class</code>, <code>Id</code>, <code>TyVar</code>) are pervasive throughout the rest of the compiler. (<code>-ddump-tc</code>)</li></ul></li></ul><blockquote><p>These three passes can all discover programmer errors, which are sorted and reported to the user.</p></blockquote>
Note the <blockquote> tag right at the end: that's the "These three passes..." part, and GitLab faithfully reproduces it as a blockquote. It just doesn't look like a blockquote on Trac, because Trac's CSS doesn't have any explicit styling rules for <blockquote>, and its default left indent happens to align with the list items.
This probably happened due to a quirk in Trac's wiki syntax: a blank line ends a list, and a two-space indented block signifies a blockquote. So if you write this:
- Lorem ipsum dolor sit amet
...then what you get is not this:
<ul><li><p>Lorem ipsum</p><p>dolor sit amet</p></li></ul>
...but rather this:
<ul><li>Lorem ipsum</li></ul><blockquote><p>dolor sit amet</p></blockquote>
But you don't notice that, because the blockquote is styled exactly like the list continuation would have.
I'm afraid I don't see a way of fixing this, other than manually.