fix(web-app-mattermost): keep the generated plugin bundle off shared storage

A newly created swarm service starts every replica at the same instant -
update_config.Parallelism governs updates, not the initial scale-up - and each
process unpacks the prepackaged plugin into /mattermost/client/plugins, which
was an NFS export shared by all of them. The loser of that race aborts with
'unable to copy webapp bundle directory: chmod .../main.js: no such file or
directory', never activates the plugin, and answers 404 on its routes for the
rest of its life while the VIP keeps sending it a share of the traffic.

Measured on the live cluster: task IPs .30 and .32 answer 401 on the plugin
route, .31 answers 404; the shared directory holds the hashed bundle and the
LICENSE file but no main.js; byte-identical nanosecond mtimes on two nodes
prove one filesystem.

client/plugins is regenerated from the plugin at every activation, so it is
per-node state. plugins/ stays shared because uploaded plugin archives live
there, and sharing the generated bundle could never substitute for activation
anyway - a replica without the plugin in its process answers 404 regardless of
what sits in the directory.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

roles/web-app-mattermost/meta/volumes.yml

@@ -30,6 +30,8 @@ plugins:
 client-plugins:
   type: volume
   name: mattermost_client_plugins
+  # nocheck: nfs-false-data-loss  Reason: unpacked from the server-side plugin bundle at every activation; shared, replicas starting at once copy into one directory and the loser then serves 404 on the plugin routes
+  nfs: false
   mounts:
     - service: mattermost
       target: /mattermost/client/plugins