Add link to new workload set documentation

release-notes/9.0/preview/preview7/sdk.md

@@ -47,24 +47,24 @@ You can see what mode your SDK installation is in by running `dotnet workload --
 
 ```terminal
 > dotnet workload --info
-Workload version: 9.0.100-manifests.400dd185
+ Workload version: 9.0.100-preview.7.24414.1
 Configured to use loose manifests when installing new manifests.
  [aspire]
-   Installation Source: VS 17.10.35027.167, VS 17.11.35111.106
-   Manifest Version:    8.0.2/8.0.100
-   Manifest Path:       C:\Program Files\dotnet\sdk-manifests\8.0.100\microsoft.net.sdk.aspire\8.0.2\WorkloadManifest.json
-   Install Type:              Msi
+   Installation Source: SDK 8.0.400
+   Manifest Version:    8.1.0/8.0.100
+   Manifest Path:       C:\Program Files\dotnet\sdk-manifests\8.0.100\microsoft.net.sdk.aspire\8.1.0\WorkloadManifest.json
+   Install Type:        FileBased
 ```
 
-In this example, I am in 'manifest' mode, which is what we call the current mode of managing workloads.
+In this example, I am in 'manifests' mode, which is what we call the current mode of managing workloads.
 The simplest way to opt into the new mode is to add a `--version` option to a `dotnet workload install` or `dotnet workload update` command, but you can also explicitly control your mode of operation using the new `dotnet workload config` command:
 
 ```terminal
 > dotnet workload config --update-mode workload-set
 Successfully updated workload install mode to use workload-set.
 ```
 
-If you need to change back for any reason, you can run the same command with `manifests` instead of `workload-set`. You can also use `dotnet workload config --update-mode` to check what the current mode of operation is. You can read more about workload sets in [our documentation]().
+If you need to change back for any reason, you can run the same command with `manifests` instead of `workload-set`. You can also use `dotnet workload config --update-mode` to check what the current mode of operation is. You can read more about workload sets in [our documentation](https://learn.microsoft.com/dotnet/core/tools/dotnet-workload-sets).
 
 ## Mitigating analyzer mismatch issues aka 'torn SDK'
 
@@ -85,4 +85,3 @@ You can read more about it [in our documentation for the effort](https://github.
 In short, the SDK's MSBuild logic embeds the version of MSBuild it shipped with, and we can use that information to detect when the SDK is running in an environment other than that version.
 
 When we detect this, the SDK inserts an implicit [PackageDownload](https://learn.microsoft.com/nuget/consume-packages/packagedownload-functionality) of a support package called `Microsoft.Net.Sdk.Compilers.Toolset` that ensures a consistent analyzer experience for users.
-