Fix pre-existing markdownlint violations in versioning.md

CI runs markdownlint-cli2 only on files changed by the PR, so the prior
commit's single-sentence addition to versioning.md surfaced 23 long-
standing violations in the same file that had been latent on main.
Fixed mechanically:

- MD029 (ordered-list prefix): continuation paragraphs under list
  items 1, 3, 4 were indented 2 spaces instead of 3, breaking them
  out of the list and making each subsequent item look like a fresh
  "1." Indented to 3 spaces so the list stays connected.
- MD005 (list-indent): item " 3." in the "How Octopus Deploy treats
  semantic versions" list had a stray leading space.
- MD004 (ul-style): two unordered lists under "Maven versions" used
  `*` bullets; the repo style is `-`.
- MD007 (ul-indent): "Learn more" list items were indented one space;
  should be column 0.

No content changes.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Author: NickJosevski

src/pages/docs/packaging-applications/create-packages/versioning.md

@@ -19,16 +19,16 @@ Consider the following factors when deciding on the versioning scheme you'll use
 
 1. Can you trace a version back to the commit/check-in the application/package was built from?
 
-  *For example: We stamp the SHA hash of the git commit into the metadata component of the Semantic Version for Octopus Deploy which makes it easier to find and fix bugs. We also tag the commit with the version of Octopus Deploy it produced so you can quickly determine which commit produced a particular version of Octopus Deploy.*
+   *For example: We stamp the SHA hash of the git commit into the metadata component of the Semantic Version for Octopus Deploy which makes it easier to find and fix bugs. We also tag the commit with the version of Octopus Deploy it produced so you can quickly determine which commit produced a particular version of Octopus Deploy.*
 
 2. Can your users easily report a version to the development team that supports #1?
 3. Will your version numbers be confusing, or will they help people understand the changes that have been made to the software?
 
-  *For example: bumping a major version component (first part) means there are potentially breaking changes, but bumping a patch (3rd part) should be safe to upgrade, and safe to rollback if something goes wrong.*
+   *For example: bumping a major version component (first part) means there are potentially breaking changes, but bumping a patch (3rd part) should be safe to upgrade, and safe to rollback if something goes wrong.*
 
 4. Does your tool chain support the versioning scheme?
 
-  *Octopus supports Semantic Versioning, which enables enhanced features like [Channels](/docs/releases/channels).*
+   *Octopus supports Semantic Versioning, which enables enhanced features like [Channels](/docs/releases/channels).*
 
 ## SemVer {#semver}
 
@@ -72,7 +72,7 @@ Octopus uses a string-based approach to version numbers. These are the decisions
         i. `3.0.0-beta.10 > 3.0.0-beta.9`  
         i. `1.4.008 < 1.4.9`  
 
- 3. **Package Feeds:** Octopus asks the feed for a package with the version string stored in the release, and accepts what the feed provides.
+3. **Package Feeds:** Octopus asks the feed for a package with the version string stored in the release, and accepts what the feed provides.
 
 ## Maven versions {#maven}
 
@@ -82,23 +82,23 @@ The Maven versioning scheme is implemented as a copy of the [ComparableVersion](
 
 Maven version strings have 5 parts:
 
-* Major
-* Minor
-* Patch
-* Build number
-* Qualifier
+- Major
+- Minor
+- Patch
+- Build number
+- Qualifier
 
 The Major, Minor, Patch, and Build number are all integer values.
 
 The Qualifier can hold any value, although some qualifiers have special meanings and an associated order of precedence as follows:
 
-* alpha or a
-* beta or b
-* milestone or m
-* rc or cr
-* snapshot
-* (the empty string) or ga or final
-* sp
+- alpha or a
+- beta or b
+- milestone or m
+- rc or cr
+- snapshot
+- (the empty string) or ga or final
+- sp
 
 Qualifiers are case-insensitive, and some of the qualifiers have shorthand aliases, for instance, `alpha` and `a`. If you use an alias it must include a number, for instance, `a1`. If you do not include a number after the alias, it will be treated as an unrecognized qualifier which will be compared as a case-insensitive string after the qualified versions.
 
@@ -110,10 +110,10 @@ For an in-depth look at Maven versions, see the blog post [Maven Versions Explai
 
 ## Learn more
 
- - [Package your applications](/docs/packaging-applications).
- - [Create packages with Octopus CLI](/docs/packaging-applications/create-packages/octopus-cli).
- - [Creating packages with OctoPack](/docs/packaging-applications/create-packages/octopack).
- - [TeamCity plugin](/docs/packaging-applications/build-servers/teamcity).
- - [Azure DevOps plugin](/docs/packaging-applications/build-servers/tfs-azure-devops/using-octopus-extension).
- - [Package repositories](/docs/packaging-applications).
- - [Package deployments](/docs/deployments/packages).
+- [Package your applications](/docs/packaging-applications).
+- [Create packages with Octopus CLI](/docs/packaging-applications/create-packages/octopus-cli).
+- [Creating packages with OctoPack](/docs/packaging-applications/create-packages/octopack).
+- [TeamCity plugin](/docs/packaging-applications/build-servers/teamcity).
+- [Azure DevOps plugin](/docs/packaging-applications/build-servers/tfs-azure-devops/using-octopus-extension).
+- [Package repositories](/docs/packaging-applications).
+- [Package deployments](/docs/deployments/packages).