worker versioning section refactor

docs/best-practices/worker.mdx

@@ -174,7 +174,7 @@ safer rollouts, clearer rollback behavior, and a cleaner operational model than
 Workflow definition.
 
 To learn more about versioning Workflows, see the
-[Workflow Versioning](/production-deployment/worker-deployments/worker-versioning.mdx) guide or take our
+[Worker Versioning](/production-deployment/worker-deployments/worker-versioning) guide or take our
 [Worker Versioning course](https://learn.temporal.io/courses/worker_versioning/).
 
 :::tip

docs/production-deployment/worker-deployments/kubernetes-controller.mdx

@@ -31,7 +31,7 @@ Over time these checks can become a source of technical debt, as safely removing
 Using pinning, you will not need to add branching to your Workflows to avoid non-determinism errors.
 This allows you to bypass the other Versioning APIs.
 
-The Worker Controller gives you direct, programmatic control over your Worker deployments, and integrates with the [Temporal CLI](/production-deployment/worker-deployments/worker-versioning#rolling-out-changes-with-the-cli).
+The Worker Controller gives you direct, programmatic control over your Worker deployments, and integrates with the [Temporal CLI](/production-deployment/worker-deployments/worker-versioning/roll-out-and-pin#rolling-out-changes-with-the-cli).
 You do not need to use the Worker Controller to use Worker Versioning, but when used together, Worker Versioning and the Worker Controller can provide more graceful deployments and upgrades, and less need to manually tune your Workers.
 
 Note that in Temporal, **Worker Deployment** is sometimes referred to as **Deployment**, but since the Worker Controller makes significant references to Kubernetes Deployment resource, within this page we will stick to these terms:

docs/production-deployment/worker-deployments/recover-pinned-workflows.mdx

@@ -125,7 +125,7 @@ For Workflows still retrying without state corruption, you may need to use the [
 
 ## Recover Workflows
 
-Temporal exposes two recovery primitives, both available through the CLI or directly through the Worker Versioning APIs (see [Moving a pinned Workflow](/production-deployment/worker-deployments/worker-versioning#moving-a-pinned-workflow)):
+Temporal exposes two recovery primitives, both available through the CLI or directly through the Worker Versioning APIs (see [Moving a pinned Workflow](/production-deployment/worker-deployments/worker-versioning/roll-out-and-pin#moving-a-pinned-workflow)):
 
 - **Versioning Override** — forces the next retried Workflow Task to execute on a different pinned Version. Use [`temporal workflow update-options`](/cli/command-reference/workflow#update-options).
 - **Reset-with-Move** — atomically resets a Workflow's Event History and applies a Versioning Override. Use [`temporal workflow reset with-workflow-update-options`](/cli/command-reference/workflow#with-workflow-update-options).
@@ -234,7 +234,7 @@ Recommended approach:
 1. Repeat the idempotent recovery commands on `Running` Workflows until the drainage status reports `drained`. The Temporal Service refreshes drainage status periodically, so it may take a few minutes after the last running Workflow closes.
 2. Once the Version is drained, run the non-idempotent Reset-with-Move command against closed Workflows once.
 
-See [Sunsetting an old Deployment Version](/production-deployment/worker-deployments/worker-versioning#sunsetting-an-old-deployment-version) for more on drainage states.
+See [Sunsetting an old Deployment Version](/production-deployment/worker-deployments/worker-versioning/sunset-and-gc#sunsetting-an-old-deployment-version) for more on drainage states.
 
 ## Clean up the drained Version