Enable rumdl markdown line-length enforcement and reflowing (#7667)

This should handle over-long lines. I had tried to make the normalize
method work, but it doesn't seem promising and so let's at least enable
this version.

Assisted-by: Antigravity with Gemini

toolchain/docs/check/cpp/thunks.md

@@ -128,14 +128,15 @@ instead we call it directly. Otherwise, we generate a thunk as follows.
 On the C++ side, we have two `clang::FunctionDecl`s:
 
 -   The original callee.
--   The thunk with a simplified ABI, which is defined to call the original callee.
+-   The thunk with a simplified ABI, which is defined to call the original
+    callee.
 
 On the Carbon side, we have two `SemIR::Function`s:
 
--   The function representing the original C++ function signature. This is marked
-    as `SpecialFunctionKind::HasCppThunk`. Attempts to call this function generate
-    a call through the thunk instead. This is returned when Carbon invokes C++
-    overload resolution.
+-   The function representing the original C++ function signature. This is
+    marked as `SpecialFunctionKind::HasCppThunk`. Attempts to call this function
+    generate a call through the thunk instead. This is returned when Carbon
+    invokes C++ overload resolution.
 -   The function representing the C++ thunk. This is the target of SemIR `call`
     instructions, and is marked as `SpecialFunctionKind::CppThunk`. This has the
     same symbol name as the C++ thunk.
@@ -164,16 +165,16 @@ When C++ code calls into Carbon, we always generate a thunk on each side.
 On the Carbon side, we have two `SemIR::Function`s:
 
 -   The original callee.
--   The thunk with a simplified ABI, which is defined to call the original callee.
-    This is marked as `SpecialFunctionKind::CppThunk`.
+-   The thunk with a simplified ABI, which is defined to call the original
+    callee. This is marked as `SpecialFunctionKind::CppThunk`.
 
 On the C++ side, we have two `clang::FunctionDecl`s:
 
 -   A C++ function representing the original Carbon function signature. This
     function is defined in the C++ AST with a body that calls the thunk; from
     Clang's perspective this is a normal C++ function.
--   A C++ function representing the Carbon thunk. This has the same symbol name as
-    the Carbon thunk.
+-   A C++ function representing the Carbon thunk. This has the same symbol name
+    as the Carbon thunk.
 
 `Context::clang_decls` can be used to map between the corresponding C++ and
 Carbon functions above. `Function::cpp_thunk_callee` can be used to map from the
@@ -211,8 +212,8 @@ class Derived {
 
 This is implemented by combining three other kinds of thunk, as follows:
 
--   A declaration of the C++ function in the base class is imported into Carbon as
-    a member of the derived class. This function is marked as being a
+-   A declaration of the C++ function in the base class is imported into Carbon
+    as a member of the derived class. This function is marked as being a
     [signature adaptation thunk](#signature-adaptation-thunks) for the Carbon
     overrider.
 -   The signature adaptation thunk is [exported to C++](#c-calling-carbon). This
@@ -220,9 +221,9 @@ This is implemented by combining three other kinds of thunk, as follows:
     adaptation thunk, and a C++-side definition.
 -   The Carbon-side thunk's call to the signature adaptation thunk is inlined in
     SemIR.
--   The C++-side function definition uses the exact signature of the original C++
-    function. We know to do this because it is a thunk generated for a signature
-    adaptation thunk whose signature is itself imported from C++.
+-   The C++-side function definition uses the exact signature of the original
+    C++ function. We know to do this because it is a thunk generated for a
+    signature adaptation thunk whose signature is itself imported from C++.
 
 In `clang_decls`, the signature adaptation thunk corresponds to the C++ virtual
 override function.
@@ -240,8 +241,8 @@ We are concerned with two vtables:
     used for constant evaluation on the Carbon side.
 -   The C++-side vtable representation. In this case, because the vptr was
     originally introduced by a C++ class, this will be used for code generation.
-    This is generated by Clang based on our exporting a suitable set of overriding
-    functions when we export the Carbon class to C++.
+    This is generated by Clang based on our exporting a suitable set of
+    overriding functions when we export the Carbon class to C++.
 
 The Carbon-side vtable contains the signature adaptation thunk. The C++-side
 vtable contains the corresponding C++ virtual override function.
@@ -293,6 +294,7 @@ We can't synthesize the definition of the C++-side virtual overrider until the
 enclosing class is complete in the C++ AST. Therefore we split the
 responsibility for generating the thunks in two:
 
--   When we complete the Carbon class, we generate the signature adaptation thunk.
--   When we form a corresponding complete C++ class type, we generate the C++-side
-    virtual overrider thunk.
+-   When we complete the Carbon class, we generate the signature adaptation
+    thunk.
+-   When we form a corresponding complete C++ class type, we generate the
+    C++-side virtual overrider thunk.