Formatting fixes to release notes

calico-enterprise_versioned_docs/version-3.19-2/release-notes/index.mdx

@@ -110,17 +110,17 @@ $[prodname] now provides the ability to set resource requests and limits for the
 * Calico panics if kube-proxy or other components are using native `nftables` rules instead of the `iptables-nft` compatibility shim. Until Calico supports native nftables mode, we recommend that you continue to use the iptables-nft compatibility layer for all components. (The compatibility layer was the only option before Kubernetes v1.29 added alpha-level `nftables` support.) Do not run Calico in "legacy" iptables mode on a system that is also using `nftables`. Although this combination does not panic or fail (at least on kernels that support both), the interaction between `iptables` "legacy" mode and `nftables` is confusing: both `iptables` and `nftables` rules can be executed on the same packet, leading to policy verdicts being "overturned".
 * When a tier order is set to the maximum float value (1.7976931348623157e+308), this can cause policy re-ordering in the UI not to work properly. Since the `namespace-isolation` tier has this value by default, policy recommendation users are affected. To workaround this issue edit any tier that has this value for the order. For example: use `kubectl edit tier namespace-isolation` and set the order to `10000`.
 * Linseed deployment needs to be manually restarted after an upgrade. Without a restart, Linseed can't ingest data because it can't authenticate with Elastic.
-<li>
+  <li>
   Some application layer features are not working as expected for $[prodname] installations with the following deployment types:
   <ul>
   <li>AKS clusters with Azure CNI for networking and $[prodname] for network policy</li>
   <li>RKE2 clusters installed with Rancher UI</li>
-    </ul>
+  </ul>
   During installation, for these deployment types, <code>kubeletVolumePluginPath</code> is set to <code>None</code> in the Installation CR, causing all application layer features to stop working.
   The affected features include web application firewalls, application layer policies, and L7 logging.
   As a workaround, you can restore the default value by running the following command on an affected cluster:
-<CodeBlock language='bash'>{`kubectl patch installation.tigera.io default --type=merge  -p '{"spec":{"kubeletVolumePluginPath":"/var/lib/kubelet"}}'`}</CodeBlock>
-</li>
+  <CodeBlock language='bash'>{`kubectl patch installation.tigera.io default --type=merge  -p '{"spec":{"kubeletVolumePluginPath":"/var/lib/kubelet"}}'`}</CodeBlock>
+  </li>
 
 ## Updating
 
@@ -130,7 +130,7 @@ $[prodname] 3.19 contains breaking changes for installations that use the Calico
 
 :::
 
-* ***Breaking change***: Upgrading from Calico Enterprise 3.18 or earlier $[prodname] will alter the UID of all `projectcalico.org/v3` resources.
+* ***Breaking change:*** Upgrading from Calico Enterprise 3.18 or earlier $[prodname] will alter the UID of all `projectcalico.org/v3` resources.
   If you're using the Calico API server, you must restart any controllers, including `kube-controller-manager`, that manage these resources after the upgrade.
   This change addresses an issue where duplicate UIDs on different API resources could disrupt Kubernetes garbage collection.
 

calico-enterprise_versioned_docs/version-3.20-2/release-notes/index.mdx

@@ -115,18 +115,17 @@ For more information, see [Packet capture](../visibility/packetcapture.mdx), [En
 * *Multi-cluster management users only*. If the `manager-tls` and `internal-manager-tls` secrets have overlapping DNS names, components such as `es-calico-kube-controllers` will log certificate errors. If you have previously installed a version older than v3.13.0 and never changed your manager-tls secret from the tigera-operator namespace, you must delete both of these secrets. This applies to you if the following command prints a certificate: `$ kubectl get secret manager-tls -n tigera-operator -o "jsonpath={.data['cert']}"`.
 * Upgrading to $[prodname] 3.18.0 on Rancher/RKE from $[prodname] 3.13.0 currently requires manually terminating the calico-node container for an upgrade to proceed.
 * Calico panics if kube-proxy or other components are using native `nftables` rules instead of the `iptables-nft` compatibility shim. Until Calico supports native nftables mode, we recommend that you continue to use the iptables-nft compatibility layer for all components. (The compatibility layer was the only option before Kubernetes v1.29 added alpha-level `nftables` support.) Do not run Calico in "legacy" iptables mode on a system that is also using `nftables`. Although this combination does not panic or fail (at least on kernels that support both), the interaction between `iptables` "legacy" mode and `nftables` is confusing: both `iptables` and `nftables` rules can be executed on the same packet, leading to policy verdicts being "overturned".
-<li>
+  <li>
   Some application layer features are not working as expected for $[prodname] installations with the following deployment types:
   <ul>
-    <li>AKS clusters with Azure CNI for networking and $[prodname] for network policy</li>
-    <li>RKE2 clusters installed with Rancher UI</li>
+  <li>AKS clusters with Azure CNI for networking and $[prodname] for network policy</li>
+  <li>RKE2 clusters installed with Rancher UI</li>
   </ul>
   During installation, for these deployment types, <code>kubeletVolumePluginPath</code> is set to <code>None</code> in the Installation CR, causing all application layer features to stop working.
   The affected features include web application firewalls, application layer policies, and L7 logging.
   As a workaround, you can restore the default value by running the following command on an affected cluster:
   <CodeBlock language='bash'>{`kubectl patch installation.tigera.io default --type=merge  -p '{"spec":{"kubeletVolumePluginPath":"/var/lib/kubelet"}}'`}</CodeBlock>
-</li>
-
+  </li>
 * When using eBPF mode with kernels older than 5.17 you may need to set `bpfDNSPolicyMode` to `NoDelay` in the `FelixConfiguration` to avoid a  possible crash loop. Some distributions using kernel version < 5.17 may work depending on which backports are present in that kernel. For instance Ubuntu kernels 5.15+ and RH kernels 5.14+ have the necessary capabilities.
 
 ## Updating