Update deployment documentation for JavaScript apps (#643)

* Update deployment documentation for JavaScript apps

Tweaks to deploying JS apps doc.

* Apply suggestions from code review

Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>

---------

Co-authored-by: David Pine <david.pine@microsoft.com>
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>

Author: 3 people

src/frontend/src/content/docs/deployment/javascript-apps.mdx

@@ -28,7 +28,7 @@ For deployment, `AddViteApp` and `AddJavaScriptApp` should be treated as fronten
 To deploy a JavaScript frontend, you must choose which other resource owns the public HTTP surface in production:
 
 - Use `PublishWithContainerFiles(...)` when your backend or web server will serve the built frontend files.
-- Use `PublishWithStaticFiles(...)` when your reverse proxy, gateway, or BFF will serve the built frontend files.
+- Use `PublishWithStaticFiles(...)` when your reverse proxy, gateway, or <abbr title="Backend for Frontend">BFF</abbr> will serve the built frontend files.
 
 If you only add a Vite or JavaScript app and reference backend services, Aspire still needs one of these production hosting patterns to know who serves the built frontend in deployment.
 
@@ -223,9 +223,9 @@ await builder.build().run();
 </Tabs>
 
 <Aside type="note">
-  `AddViteApp` is still fine in this model. The trap is not `AddViteApp` itself
-  — it is treating the Vite development server endpoint as a publish-time
-  dependency.
+  `AddViteApp` is still fine in this model but it's important to
+  understand that the Vite development server endpoint is not used at
+  publish-time.
 </Aside>
 
 ### Dev-only gateway wiring