[Pre4] Nix a couple of dotnet.boot.js file mentions

aspnetcore/blazor/host-and-deploy/webassembly/bundle-caching-and-integrity-check-failures.md

@@ -20,7 +20,7 @@ When a Blazor WebAssembly app loads in the browser, the app downloads boot resou
 * .NET runtime and assemblies
 * Locale specific data
 
-Except for Blazor's boot manifest file (`dotnet.boot.js` in .NET 10 or later, `blazor.boot.json` prior to .NET 10), WebAssembly .NET runtime and app bundle files are cached on clients. The Blazor boot configuration contains a manifest of the files that make up the app that must be downloaded along with a hash of the file's content that's used to detect whether any of the boot resources have changed. Blazor caches downloaded files using the browser [Cache](https://developer.mozilla.org/docs/Web/API/Cache) API.
+Except for Blazor's boot manifest file (`blazor.boot.json` ) prior to the release of .NET 10, WebAssembly .NET runtime and app bundle files are cached on clients. The Blazor boot configuration, inlined into `dotnet.js` in .NET 10 or later, contains a manifest of the files that make up the app that must be downloaded along with a hash of the file's content that's used to detect whether any of the boot resources have changed. Blazor caches downloaded files using the browser [Cache](https://developer.mozilla.org/docs/Web/API/Cache) API.
 
 When Blazor WebAssembly downloads an app's startup files, it instructs the browser to perform integrity checks on the responses. Blazor sends SHA-256 hash values for DLL (`.dll`), WebAssembly (`.wasm`), and other files in the Blazor boot configuration, which isn't cached on clients. The file hashes of cached files are compared to the hashes in the Blazor boot configuration. For cached files with a matching hash, Blazor uses the cached files. Otherwise, files are requested from the server. After a file is downloaded, its hash is checked again for integrity validation. An error is generated by the browser if any downloaded file's integrity check fails.
 

aspnetcore/release-notes/aspnetcore-10/includes/blazor.md

@@ -194,13 +194,15 @@ The default environments are:
 * `Development` for build.
 * `Production` for publish.
 
-### Boot configuration file name change
+### Boot configuration file inlined
 
-The boot configuration file is changing names from `blazor.boot.json` to `dotnet.boot.js`. This name change only affects developers who are interacting directly with the file, such as when developers are:
+Blazor's boot configuration, which prior to the release of .NET 10 existed in a file named `blazor.boot.json`, has been inlined into the `dotnet.js` script. This only affects developers who are interacting directly with the `blazor.boot.json` file, such as when developers are:
 
 * Checking file integrity for published assets with the troubleshoot integrity PowerShell script per the guidance in <xref:blazor/host-and-deploy/webassembly/bundle-caching-and-integrity-check-failures?view=aspnetcore-9.0#troubleshoot-integrity-powershell-script>.
 * Changing the file name extension of DLL files when not using the default Webcil file format per the guidance in <xref:blazor/host-and-deploy/webassembly/index?view=aspnetcore-9.0#customize-how-boot-resources-are-loaded>.
 
+Currently, there's no documented replacement strategy for the preceding approaches. If you require either of the preceding strategies, open a new documentation issue describing your scenario using the **Open a documentation issue** link at the bottom of either article.
+
 ### Declarative model for persisting state from components and services
 
 You can now declaratively specify state to persist from components and services using the `[SupplyParameterFromPersistentComponentState]` attribute. Properties with this attribute are automatically persisted using the <xref:Microsoft.AspNetCore.Components.PersistentComponentState> service during prerendering. The state is retrieved when the component renders interactively or the service is instantiated.