Adds a shared/modules symlink mechanism for optional plugin modules

ModuleOrchestrator already discovers SlpModularCms.Modules.*.dll from disk at
startup via reflection, so this needed no code change — only a persistent
location (mirroring shared/wwwroot-web) that survives release swaps, and a
deploy-scp.yaml step to symlink its contents into each new release before
restart.

aidlc-docs/features/gitea-deployment-workflow/operations/deployment/deployment-instructions.md

@@ -148,6 +148,28 @@ sudo chgrp -R webshared /mnt/storage1/www/html/slpsoftware/<env>
 and make sure webadmin's FTP server creates new uploads group-readable (`g+rx`, not just
 owner-readable) — a one-time permission setup, not something either pipeline touches per deploy.
 
+**`shared/modules` is the equivalent mechanism for optional plugin modules** (future modular
+support) — but simpler, since it lives entirely under `gitea-workflow`'s own tree, with no
+cross-account permission dance:
+
+👤 **pi-main / `gitea-workflow`:**
+```bash
+mkdir -p ~/apps/slpsoftware/<env>/shared/modules
+```
+
+`deploy-scp.yaml`'s "Link persistent modules" step already runs this `mkdir -p` on every deploy, so
+this line is only useful if you want the directory to exist before the very first deploy — it isn't
+required. To add a module: build a `SlpModularCms.Modules.<Name>.dll` against the same version of
+`SlpModularCms.Core` the running app was built against (mismatched contracts are caught per-module
+by `ModuleOrchestrator`'s existing try/catch — logged and skipped, not a crash), `scp`/`sftp` it as
+`gitea-workflow` into `~/apps/slpsoftware/<env>/shared/modules/`, then either wait for the next
+deploy or restart the service by hand:
+```bash
+systemctl --user restart slpsoftware-<env>.service
+```
+Either way, `ModuleOrchestrator.DiscoverModules()` picks it up from the release directory the next
+time the process starts — no CI run required to add a module this way.
+
 ### 1.5 Runtime Configuration File
 One file per environment, **outside** the release directory so it survives every switch:
 
@@ -498,9 +520,9 @@ Already built (U5/U6) — this is the read-only walkthrough for whoever operates
 1. Push to `master`, or a manual `workflow_dispatch` → the six gates run
 2. `publish-test` runs (and `publish-production`, only if `workflow_dispatch` with the flag)
 3. `deploy-test` (always, if gates pass) calls `deploy-scp.yaml`, which uploads into a new
-   `releases/{timestamp}/`, links `shared/wwwroot-web` in, switches `current`, restarts
-   `slpsoftware-test.service`, verifies `https://test.slpsoftware.nl/health`, then prunes old
-   releases (only test — `run_db_backup: false`)
+   `releases/{timestamp}/`, links `shared/wwwroot-web` and any `shared/modules/*.dll` in, switches
+   `current`, restarts `slpsoftware-test.service`, verifies `https://test.slpsoftware.nl/health`,
+   then prunes old releases (only test — `run_db_backup: false`)
 4. `deploy-production` (only with the flag) does the same, plus a database backup first
    (`run_db_backup: true`) — see § 4