Fix lint warning, make these unordered lists

docs/pages/management/operations/upgrading.mdx

@@ -3,8 +3,7 @@ title: Upgrading a Teleport Cluster
 description: This guide shows you the correct order in which to upgrade Teleport components when rolling out a new Teleport release in your cluster.
 ---
 
-In this guide, we will show you how to upgrade all of the components in your
-Teleport cluster.
+This guide demonstrates how to upgrade all of the components in your Teleport cluster.
 
 (!docs/pages/includes/cloud/call-to-action.mdx!)
 
@@ -28,13 +27,14 @@ title="Auth Service and Proxy Service versions">
 
 In Teleport Cloud, we manage the Auth and Proxy Services for you. You can
 determine the current version of these services by running the following
-command, where `mytenant` is the name of your Teleport Cloud tenant:
+command, where `mytenant` is the name of your Teleport Team or Teleport 
+Enterprise Cloud tenant:
 
 ```code
 $ curl -s https://mytenant.teleport.sh/webapi/ping | jq '.server_version'
 ```
 
-Read the following rules to ensure that your Teleport resource services (e.g.,
+Read the following rules to ensure that your Teleport resource services (for example,
 the SSH Service and Database Service) are compatible with the Teleport Auth and
 Proxy Services. You should check the version of the Auth and Proxy Services
 regularly to make sure that your Teleport resource services are compatible.
@@ -47,28 +47,30 @@ regularly to make sure that your Teleport resource services are compatible.
 
 Back up before upgrading. We have more instructions in [Backing up Teleport](./backup-restore.mdx).
 
-## Upgrade Sequence
+## Upgrade sequence
 
 <Tabs>
 <TabItem scope={["enterprise", "oss"]} label="Self-Hosted">
-When upgrading a single Teleport cluster:
 
-<Notice type="tip">
 Teleport requires upgrading the Teleport Cluster from one major version to another in sequence.
-That means if you are currently on version 8.X you must upgrade to the latest version 9 before
-going to version 10. To upgrade in sequence repeat upgrading the Teleport Cluster, confirming
+If you are currently on version 11.x, you must upgrade to the latest version 12.x before
+going to version 13.x. To upgrade in sequence, upgrade the Teleport cluster and confirm
 a healthy start before continuing to the next version.
-</Notice>
 
-1. **Upgrade the Auth Service first to the next Major version**. The Auth Service keeps the cluster state
-   and, if there are data format changes introduced in the new version, will
-   perform necessary migrations.  Confirm the start of the Auth Service and a healthy state.
-2. Upgrade Proxy Service instances to the same version number. These are stateless and can be upgraded in
-   any sequence or at the same time.
-3. Finally, upgrade your Teleport resource services in any sequence or at the
-   same time to the same version number.
-4. If you are upgrading more then one version number then repeat Step 1 to 3 until you have reached your target
-   major version.
+When upgrading a single Teleport cluster:
+
+- Upgrade the **Auth Service** to the next **major version first**. 
+   The Auth Service keeps the cluster state. If there are data format 
+   changes introduced in the new version, the Auth Service performs the necessary migrations.  
+   After the upgrade, start the Auth Service and CONFIRM that it's in a healthy state before
+   continuing.
+- Upgrade Proxy Service instances to the same version number as the Auth Service. 
+   Proxy Service instances are stateless and can be upgraded in any sequence or at the same time.
+- Upgrade your Teleport resource services to the same version number as the Auth Service.
+   You can upgrade resource agents in any sequence or at the same time.
+
+If you are upgrading more then one version number, repeat these steps until 
+you reach your target major version number.
 
 <Admonition
   type="warning"
@@ -85,8 +87,9 @@ precaution. This allows for a safe rollback in case the migration itself fails.
 
 When upgrading multiple clusters:
 
-1. First, upgrade the root cluster, i.e. the one that other clusters trust.
-2. Upgrade the Trusted Clusters.
+- Upgrade the root cluster—that is, the cluster that other clusters trust—first.
+- Verify the upgrade was successful.
+- Upgrade the Trusted Clusters.
 
 </TabItem>
 <TabItem scope={["cloud","team"]} label="Cloud-Hosted">
@@ -97,8 +100,9 @@ time.
 
 When upgrading multiple clusters:
 
-1. First, upgrade the root cluster, i.e. the one that other clusters trust.
-2. Upgrade the Trusted Clusters.
+- Upgrade the root cluster—that is, the cluster that other clusters trust—first.
+- Verify the upgrade was successful.
+- Upgrade the Trusted Clusters.
 
 </TabItem>
 </Tabs>

docs/pages/reference/audit.mdx

@@ -9,18 +9,18 @@ There are two components of the audit log:
 <Tabs>
 <TabItem scope={["enterprise", "oss"]} label="Self-Hosted">
 
-1. **Cluster Events:** Teleport logs events like successful user logins along
+- **Cluster Events:** Teleport logs events like successful user logins along
    with metadata like remote IP address, time, and the session ID.
-2. **Recorded Sessions:** Every SSH, desktop, or Kubernetes shell session is recorded and
+- **Recorded Sessions:** Every SSH, desktop, or Kubernetes shell session is recorded and
    can be replayed later. By default, the recording is done by Teleport Nodes,
    but can be configured to be done by the proxy.
 
 </TabItem>
 <TabItem scope={["cloud","team"]} label="Cloud-Hosted">
 
-1. **Cluster Events:** Teleport logs events like successful user logins along
+- **Cluster Events:** Teleport logs events like successful user logins along
    with metadata like remote IP address, time, and the session ID.
-2. **Recorded Sessions:** Every SSH, desktop, or Kubernetes shell session is recorded and
+- **Recorded Sessions:** Every SSH, desktop, or Kubernetes shell session is recorded and
    can be replayed later. Teleport Cloud manages the storage of session
    recording data.
 

docs/pages/server-access/getting-started.mdx

@@ -10,8 +10,8 @@ issuing commands through a CLI or programmatically to an API.
 This guide introduces some of these common scenarios and how to interact with
 Teleport to accomplish them:
 
-1. SSH into a cluster using Teleport.
-2. Introspect the cluster using Teleport features.
+- SSH into a cluster using Teleport.
+- Introspect the cluster using Teleport features.
 
 <Admonition type="tip" title="Tip">
 This guide also demonstrates how to configure Teleport Nodes using the **bastion

docs/pages/server-access/guides/restricted-session.mdx

@@ -39,14 +39,15 @@ Teleport supports network restrictions with more types coming in the future.
 
 - (!docs/pages/includes/tctl.mdx!)
 
-## Network Restrictions
+## Network restrictions
 
 Network restrictions work similarly to a firewall but with several differences:
-1. Firewall rules apply to the entire machine whereas network restrictions are applied
+
+- Firewall rules apply to the entire machine whereas network restrictions are applied
    only to SSH sessions.
-2. Whereas firewall typically blocks ingress (inbound) connections, network restrictions
+- Whereas firewall typically blocks ingress (inbound) connections, network restrictions
    block egress (outbound) connections.
-3. Firewall rules are typically static but Teleport provides an API for
+- Firewall rules are typically static but Teleport provides an API for
    Restricted Sessions that allows the rules to be dynamically updated across
    the entire fleet.
 

docs/pages/server-access/introduction.mdx

@@ -10,10 +10,10 @@ giving complete visibility over all sessions and events.
 
 Teleport server access is designed for the following kinds of scenarios:
 
-1. When up to a vast number of clusters must be managed using the command-line (`tsh`) or programmatically (through the Teleport API) and you want to simplify your stack, security, and configuration complexity.
-2. When security team members must track and audit every user session. 
-3. When Teleport users require a complete, dedicated, and secure SSH option (Teleport Node running in SSH mode) and more than a certificate authority (Teleport Auth) with proxy (Teleport Proxy).
-4. When resource and network security must be maximized: SSH certificates over secret keys, Two-Factor Authentication (2FA), Single Sign-On (SSO), and short-lived certificates.
+- When up to a vast number of clusters must be managed using the command-line (`tsh`) or programmatically (through the Teleport API) and you want to simplify your stack, security, and configuration complexity.
+- When security team members must track and audit every user session. 
+- When Teleport users require a complete, dedicated, and secure SSH option (Teleport Node running in SSH mode) and more than a certificate authority (Teleport Auth) with proxy (Teleport Proxy).
+- When resource and network security must be maximized: SSH certificates over secret keys, Two-Factor Authentication (2FA), Single Sign-On (SSO), and short-lived certificates.
 
 ## Getting started