fix: preserve plugin manifest compatibility

docs/plugins.html

@@ -395,10 +395,12 @@ After editing, check the manifest endpoint and browser-console failure cases.</c
                 the remote machine exposes its own copy.
               </p>
               <p>
-                Current PI WEB manifests publish module references relative to the fetched manifest, so local and
-                federated plugin modules follow root or nested reverse-proxy deployments without a prefix-specific
-                build. The browser and federated gateway also accept leading-root module references emitted by existing
-                PI WEB releases and keep them inside the current application base.
+                Current PI WEB manifests publish leading application-root module references. The browser keeps them
+                inside the current application base, so local and federated plugins follow root or nested reverse-proxy
+                deployments without a prefix-specific build while remaining compatible with existing gateways.
+                Federated gateways also accept manifest-relative references such as
+                <code>./&lt;plugin-id&gt;/plugin.js</code> and legacy plugin-root-relative references such as
+                <code>nested/plugin.js</code> from remote machines.
               </p>
               <p>
                 For portable plugin assets, prefer URLs relative to the plugin module, such as

docs/plugins.md

@@ -325,14 +325,14 @@ Rules:
 
 ### Manifest and assets
 
-The manifest contains each discovered plugin module. Current PI WEB releases emit `module` relative to the fetched manifest so the same manifest works at the origin root or under a reverse-proxy path prefix:
+The manifest contains each discovered plugin module. Current PI WEB releases emit `module` as a leading application-root reference:
 
 ```json
 {
   "plugins": [
     {
       "id": "my-plugin",
-      "module": "./my-plugin/pi-web-plugin.js?v=1234567890",
+      "module": "/pi-web-plugins/my-plugin/pi-web-plugin.js?v=1234567890",
       "source": "local",
       "scope": "local",
       "machineSpecific": false
@@ -341,7 +341,7 @@ The manifest contains each discovered plugin module. Current PI WEB releases emi
 }
 ```
 
-The browser resolves manifest-relative module references against the manifest URL. For backward compatibility, it also treats leading-root references such as `/pi-web-plugins/my-plugin/pi-web-plugin.js` from existing PI WEB releases as application-root input, not origin-root input. Federated gateways accept both forms from remote machines and rewrite them to deployment-portable, gateway-relative references.
+The browser maps leading application-root references into the current application base, so the same manifest works at the origin root or under a reverse-proxy path prefix. Keeping this output format also lets gateways from existing PI WEB releases consume plugins from an upgraded remote machine. For compatibility, federated gateways additionally accept explicit manifest-relative references such as `./my-plugin/pi-web-plugin.js` and legacy plugin-root-relative references such as `nested/pi-web-plugin.js`; all accepted forms are rewritten to deployment-portable, gateway-relative references.
 
 `source` describes where the plugin came from (`bundled`, `local`, or the Pi package source). `scope` is `bundled`, `local`, `user`, or `project`. `machineSpecific` controls whether the gateway copy is valid for remote machines or only each selected machine's own copy can appear.