DEVDOCS-6672 - Add note that catalyst main branch is deprecated (#1226)

<!-- Ticket number or summary of work -->
# [DEVDOCS-6672]


## What changed?
<!-- Provide a bulleted list in the present tense -->
* Updated Catalyst versioning documentation to note that the `main`
branch has ben deprecated.

## Release notes draft
* Updated Catalyst versioning documentation to note that the `main`
branch has ben deprecated.

ping @jamesqquick @CNanninga 


[DEVDOCS-6672]:
https://bigcommercecloud.atlassian.net/browse/DEVDOCS-6672?atlOrigin=eyJpIjoiNWRkNTljNzYxNjVmNDY3MDlhMDU5Y2ZhYzA5YTRkZjUiLCJwIjoiZ2l0aHViLWNvbS1KU1cifQ

Author: chris-nowicki

docs/storefront/catalyst/getting-started/versioning.mdx

@@ -4,9 +4,14 @@ Catalyst follows a structured versioning approach to distinguish between stable
 
 To stay updated on our releases, check out the Catalyst [releases page](https://github.com/bigcommerce/catalyst/releases) and the [changelog](https://github.com/bigcommerce/catalyst/blob/canary/core/CHANGELOG.md) on GitHub.
 
+<Callout type='warning'>
+	The `main` branch is deprecated. The `canary` branch is now the default branch
+	for the Catalyst repository and should be used instead of `main`.
+</Callout>
+
 ## How we use branches
 
-The `canary` branch contains the latest code in development and is the default branch for the Catalyst repository instead of `main`. Note that the most recent commit in `canary` may not be stable.
+The `canary` branch contains the latest code in development and is the default branch for the Catalyst repository. Note that the most recent commit in `canary` may not be stable.
 
 For the most recent stable code, refer to [How we use tags](#how-we-use-tags) below.
 
@@ -81,17 +86,17 @@ While the exact steps you need to follow vary widely depending on how you've con
    git merge @bigcommerce/catalyst-makeswift@latest
    ```
 
-<Callout type="warning">
-  If you originally created your Catalyst project based on the version of
-  Catalyst without Makeswift, you will need to merge the latest
-  `@bigcommerce/catalyst-core@latest` tag into your interim branch instead of
-  the `@bigcommerce/catalyst-makeswift@latest` tag.
+<Callout type='warning'>
+	If you originally created your Catalyst project based on the version of
+	Catalyst without Makeswift, you will need to merge the latest
+	`@bigcommerce/catalyst-core@latest` tag into your interim branch instead of
+	the `@bigcommerce/catalyst-makeswift@latest` tag.
 </Callout>
 
 5. Resolve any merge conflicts that arise. After resolving any merge conflicts, open a new PR in GitHub to merge your `your-interim-sync-branch` into `your-primary-development-branch`. This PR should be code reviewed and approved by your team before the next steps.
 
 6. Once your PR is approved, the next step is to incorporate the merge commit from `your-interim-sync-branch` into `your-primary-development-branch`. There are a few ways to do this, and the best approach for you will depend on your workflow. Here are a couple of options:
-   
+
    - **Option 1: Merge your interim branch into your primary development branch using the GitHub UI:** This is the recommended approach if you are not comfortable with using the command line.
 
    - **Option 2: Rebase your primary development branch on top of your interim branch release:** This is the recommended approach if you are comfortable with using the command line, and want to keep your commit history clean.
@@ -101,13 +106,13 @@ While the exact steps you need to follow vary widely depending on how you've con
    git rebase your-interim-sync-branch
    ```
 
-<Callout type="info" emoji="ℹ️">
-  Regardless of which option you choose, your goal is to incorporate the merge
-  commit (the commit with two parent commits) from `your-interim-sync-branch`
-  into `your-primary-development-branch`. This has the effect of establishing a
-  new merge base for your primary development branch, so that the next time you
-  pull in updates from `upstream`, you will not have to resolve any merge
-  conflicts that you've already resolved in your interim branch.
+<Callout type='info'>
+	Regardless of which option you choose, your goal is to incorporate the merge
+	commit (the commit with two parent commits) from `your-interim-sync-branch`
+	into `your-primary-development-branch`. This has the effect of establishing a
+	new merge base for your primary development branch, so that the next time you
+	pull in updates from `upstream`, you will not have to resolve any merge
+	conflicts that you've already resolved in your interim branch.
 </Callout>
 
 7. If you went with option 2 above, you have one more step to complete. Push your changes to the remote `your-primary-development-branch`, which will automatically close the PR you opened in step 5: