fix(docs): correct nested list rendering in docs site

docs/ensnode.io/src/content/docs/docs/reference/contributing/prs.mdx

@@ -8,22 +8,23 @@ sidebar:
 # Pull Request Templates
 
 We use pull request templates to help guide contributors through the process of creating a pull request.
+
 - [Lite PR](https://github.com/namehash/ensnode/blob/main/.github/pull_request_template.md)
-  - *The default PR template for non-significant or low-risk changes.*
+  - _The default PR template for non-significant or low-risk changes._
 - [Substantial PR](https://github.com/namehash/ensnode/blob/main/.github/PULL_REQUEST_TEMPLATE/substantial.md)
-  - *Template for significant changes or PRs that are complex or higher-risk to review.*
+  - _Template for significant changes or PRs that are complex or higher-risk to review._
 
 # Standard PR Process
 
 1. Apply the appropriate [Pull Request Template](#pull-request-templates) based on the nature of the changes.
 2. Create your PR as a "Draft" first until it is ready for review.
 3. Complete all of your work, self-reviews, and PR description updates on the PR.
-  - If your PR aims to close an issue, [link the PR to the issue through the PR description](https://docs.github.com/en/issues/tracking-your-work-with-issues/using-issues/linking-a-pull-request-to-an-issue#linking-a-pull-request-to-an-issue-using-a-keyword).
+   - If your PR aims to close an issue, [link the PR to the issue through the PR description](https://docs.github.com/en/issues/tracking-your-work-with-issues/using-issues/linking-a-pull-request-to-an-issue#linking-a-pull-request-to-an-issue-using-a-keyword).
 4. Complete all checkboxes on the PR description.
 5. Convert the PR from "Draft" to "Ready for Review".
 6. Wait for automated PR reviews from Greptile and GitHub Copilot. Resolve any of their suggestions as appropriate.
-  - After applying updates, if you want Greptile to make additional follow-up reviews, add a comment to the PR with the phrase "@greptile".
-  - GitHub Copilot will automatically re-review each push to the PR.
+   - After applying updates, if you want Greptile to make additional follow-up reviews, add a comment to the PR with the phrase "@greptile".
+   - GitHub Copilot will automatically re-review each push to the PR.
 7. Send a message to notify the ENSNode team that the PR is ready for manual-review.
 
 # Changesets
@@ -39,6 +40,7 @@ A "logical change" is a cohesive set of related modifications that share a commo
 Changesets should not be created robotically for every "logical change" in a PR. We create changesets specifically for the purposes of managing version bumps and autogenerated release notes.
 
 Only the following types of "logical changes" should be documented in a changeset:
+
 - Changes that should bump versions.
 - Changes that are relevant to communicate to the ENS ecosystem in release notes.
 
@@ -49,6 +51,7 @@ If a PR does not introduce any "logical changes" meeting the above criteria then
 Ensure that each "logical change" described in a changeset is appropriately mapped to the relevant package/app.
 
 Example: assume changes A, B, and C in a PR pass the criteria for changesets, with the following applicability: change A applies only to package/app X, change B applies to both package/app X and package/app Y, and change C applies only to package/app Y. This means multiple distinct changesets should be created as follows:
+
 - Changeset 1: Documenting change A for package/app X
 - Changeset 2: Documenting change B for package/app X and package/app Y
 - Changeset 3: Documenting change C for package/app Y
@@ -62,15 +65,16 @@ When you open a PR you should include relevant changeset files that document you
 1. Run `pnpm changeset` in the monorepo root.
 2. Select the packages/apps that the "logical change" affects using the interactive prompt.
 3. Choose the version bump type:
-  - *NOTE: At this time, we are NOT using [semantic versioning](https://semver.org/). Breaking changes are classified as "minor" rather than "major".*
-  - "major" - currently reserved only for specially approved cases
-  - "minor" - breaking changes (note: ENSNode doesn't follow standard semver where breaking = major)
-  - "patch" - non-breaking changes
+   - _NOTE: At this time, we are NOT using [semantic versioning](https://semver.org/). Breaking changes are classified as "minor" rather than "major"._
+   - "major" - currently reserved only for specially approved cases
+   - "minor" - breaking changes (note: ENSNode doesn't follow standard semver where breaking = major)
+   - "patch" - non-breaking changes
 4. Write a clear description of the "logical change" - this will appear in the next autogenerated release notes.
 
 The `changesets/bot` will automatically comment on your PR to either remind you to add a changeset or confirm the version changes that will happen when your PR is merged.
 
 **Important notes:**
+
 - Changesets should optimize for the narrative of the next [autogenerated release notes](https://github.com/namehash/ensnode/releases). Optimize for how the resulting release notes will read to a developer in the ENS Ecosystem. Communicate all ideas with a positive frame by emphasizing benefits to users, describing fixes in terms of what now works, and using active, solution‑oriented language rather than focusing on past problems.
 - All apps and packages in the ENSNode monorepo use "fixed" versioning - they all share the same version number regardless of which app or package triggered the version bump.
   - An exception to the above "fixed" versioning is the "fallback-ensapi" app. This is a Lambda containing logic specific to NameHash deployments of ENSNode and is therefore versioned independently.

docs/ensnode.io/src/styles/starlight.css

@@ -154,20 +154,19 @@ a[rel="prev"]:hover {
   display: inline;
 }
 
-.sl-markdown-content ul {
-  list-style: disc;
+.sl-markdown-content > :where(ul, ol) {
   color: var(--sl-color-text);
-  list-style-position: inside;
+  margin-block: 1em;
+  margin-inline: 0;
+  padding-inline-start: 40px;
 }
 
-.sl-markdown-content ul ul {
-  margin-left: 1rem;
+.sl-markdown-content ul {
+  list-style: disc;
 }
 
 .sl-markdown-content ol {
   list-style: decimal;
-  color: var(--sl-color-text);
-  list-style-position: inside;
 }
 
 .sl-markdown-content ol li::marker,