Address review: move links to end, promote heading, apply text suggestion, move Note to ARM section

Agent-Logs-Url: https://github.com/Azure/typespec-azure/sessions/557330e7-cce9-4916-94ca-12a9636bc60c

Co-authored-by: markcowl <1054056+markcowl@users.noreply.github.com>

Author: Copilot

website/src/content/docs/docs/howtos/Versioning/01-about-versioning.md

@@ -3,10 +3,6 @@ title: Introduction
 llmstxt: true
 ---
 
-See [`@typespec/versioning` documentation](https://typespec.io/docs/libraries/versioning/guide) for the general versioning concept. This guide expands on how Azure Services should define and manage API versions.
-
-See [Evolving APIs using the Versioning Library](./06-evolving-apis.md) for how to make specific kinds of common API changes in your specs.
-
 ## How Versioning Works in TypeSpec
 
 TypeSpec uses a versioning library that models the changes in each new version of the API, rather than having a separate API description for each api-version. This works well when APIs evolve according to versioning guidelines, without breaking changes. For the most part, this means that this system is very good at modeling differences between stable api-versions for Azure APIs, but can be cumbersome when describing differences between preview APIs.
@@ -28,11 +24,11 @@ These documents add specific guidance about how to follow these guidelines for s
 - [How to add a new preview version when the last version was stable](./04-preview-after-stable.md)
 - [How to add a new stable version when the last version was stable](./05-stable-after-stable.md)
 
-This document describes how to convert an existing multi-API TypeSpec spec with multiple previews into a spec with a single active preview. Note that this is not required, but it may significantly simplify the versioning decoration in your spec:
+The following document describes how to convert an existing multi-API TypeSpec spec with multiple previews into a spec with a single active preview. Note that this is not required, but it may significantly simplify the versioning decoration in your spec:
 
 - [How to convert a spec with multiple preview versions into a spec with a single active preview](./uncommon-scenarios/01-converting-specs.md)
 
-### Uncommon Scenarios
+## Uncommon Scenarios
 
 Additionally, there are some (ARM) services that may always have features that remain in preview after a stable version is released. This can happen, for example, if there are multiple independent teams that own different resources in a service and operate on their own schedule. The recommended way to handle this scenario is to model your ARM ResourceProvider as multiple services, so each sub-service and the corresponding SDKs can version independently. For some older services, this is not an option, so there is specialized guidance on how to maintain preview features over stable API releases (described below). If you are thinking about splitting your service, or about creating a new preview version with every stable version, be sure to have a discussion with the [Azure API Stewardship Board](https://aka.ms/azapi/officehours) and the [Azure SDK team](https://eng.ms/docs/products/azure-developer-experience/onboard) first.
 
@@ -54,3 +50,8 @@ It is safe to remove the swagger for an old API version if any of the following
 - The OpenAPI document in the azure-rest-api-specs repo is not needed for ARM registration
 
 It is recommended that preview api-versions are set for retirement within 90 days when a preview or stable API is introduced. See the [Azure Retirement Policy](https://aka.ms/AzureRetirementPolicy) and [Azure Retirement Process](https://aka.ms/cpexretirementsprocess) for details.
+
+## Additional Information on TypeSpec Versioning
+
+- [`@typespec/versioning` documentation](https://typespec.io/docs/libraries/versioning/guide) for the general versioning concept.
+- [Evolving APIs using the Versioning Library](./06-evolving-apis.md) for how to make specific kinds of common API changes in your specs.

website/src/content/docs/docs/howtos/Versioning/06-evolving-apis.md

@@ -40,6 +40,8 @@ After defining your enum, link it to your namespace using the `@versioned` decor
 namespace Microsoft.ContosoProviderHub;
 ```
 
+> **Note:** Add dependencies and common types for each version. After defining a new version, the emitter will produce outputs for all versions. You can then adapt your TypeSpec code for the latest version.
+
 **Data-plane example:**
 
 ```tsp
@@ -53,8 +55,6 @@ enum Versions {
 namespace DemoService;
 ```
 
-> **Note:** Add dependencies and common types for each version. After defining a new version, the emitter will produce outputs for all versions. You can then adapt your TypeSpec code for the latest version.
-
 ## Simple Scenarios
 
 These examples show how to add models, operations, properties, and parameters in specific versions using TypeSpec versioning decorators.