Merge main (PRs #5, #7, #9, #10) into the PCO Plan branch

Resolves the admin form conflicts in favour of this branch's grouped /
collapsible / dependent-select additions (the base hunks were the timers
lane's, ported verbatim), keeps both sides of the README and module-guide
edits, and adopts main's versioning rules: the shell moves to 1.3.0 for the
new schema features (configGroups / instanceGroups, help, color fields,
grouped and dependent selects) and pco-plan 1.3.0 declares
"proddash": ">=1.3.0".

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>

docs/MODULE-GUIDE.md

@@ -9,6 +9,31 @@ their own dashboards, move and resize them, and give each tile its own
 per-tile settings. Your module renders inside the tile and talks to the
 outside world only through the small API the shell hands it.
 
+## Rules every module follows
+
+These are not style preferences — the admin page, the installer and the
+people running the booth depend on them.
+
+1. **All settings live in the ProdDash admin page.** Server-wide settings go
+   in `configSchema`, per-tile settings in `instanceSchema`. Never a separate
+   setup page, wizard, config file the operator edits by hand, or environment
+   variable.
+2. **Dependencies ship inside the module folder.** Zero dependencies is the
+   norm (the shell has none). Anything you genuinely need is vendored into
+   the module — or fetched by your own `init()` on first start, with the
+   admin health line saying what is happening. No `npm install`, no
+   installer, no "run this first".
+3. **Everything the module does runs inside the module.** No helper scripts,
+   companion programs, daemons or services the operator has to start next to
+   ProdDash. If your feature needs a listener, a decoder or a worker, your
+   server entry owns it: start it in `init()`, stop it in `stop()`, report
+   it in `health()`. A child process the module itself spawns and supervises
+   is fine; a program someone launches by hand is not.
+4. **Declare the ProdDash version you need** (`"proddash": ">=1.1.0"` in the
+   manifest) and **bump your own `version`** whenever you change the module.
+   The admin page refuses to install a module whose requirement the running
+   shell doesn't meet, and it offers updates by comparing versions.
+
 ## The shape of a module
 
 A module is one folder dropped into `modules/`:
@@ -21,9 +46,16 @@ modules/<id>/
 └── ... assets       (css, images…) served statically at /modules/<id>/
 ```
 
-**Installation is exactly this:** copy the folder into `modules/`, restart
-ProdDash (`node server.js`), then configure and enable it at `/admin`. No
-shell code changes, ever.
+**Installation is exactly this:** in the admin page, open **Available
+modules** and press **Install** — the module is downloaded from the ProdDash
+repo into the server's data directory (`<data dir>/modules/<id>/`) and starts
+immediately. Developing locally? Drop the folder into `modules/` (bundled
+with the checkout) or into the data directory's `modules/` and restart. No
+shell code changes, ever. Modules bundled with a checkout and modules
+installed from the admin page live side by side; when both have the same id
+the newer version runs. **Uninstall** in the admin page removes an installed
+module's files (a bundled one is hidden instead, since its folder belongs to
+the app); its settings are kept for a later reinstall.
 
 ## module.json
 
@@ -32,6 +64,7 @@ shell code changes, ever.
   "id": "my-module",
   "name": "My Module",
   "version": "1.0.0",
+  "proddash": ">=1.1.0",
   "description": "One line shown in the Add-tile picker and the admin page",
   "client": "client.js",
   "server": "server.js",
@@ -52,7 +85,9 @@ shell code changes, ever.
 | --- | --- | --- |
 | `id` | yes | Must equal the folder name. Lowercase, dashes. |
 | `name` | yes | Human name shown on the tile header and in menus. |
-| `version`, `description` | no | Shown in the admin page / picker. |
+| `version` | yes | Your module's version (`x.y.z`). Bump it on every change — the admin page offers updates when the repo's copy is newer than the installed one. |
+| `proddash` | yes | The ProdDash versions this module works with: `">=1.1.0"`, `"^1.1.0"`, `">=1.1.0 <2.0.0"`, or `"*"`. A module whose requirement the running shell doesn't meet is listed in the admin page but never loaded, and can't be installed from the catalog. |
+| `description` | no | Shown in the admin page / picker. |
 | `client` | yes | Client entry file, loaded as an ES module. |
 | `server` | no | Server entry file (CommonJS), loaded with `require()`. |
 | `style` | no | A stylesheet the shell injects once per module. |
@@ -523,7 +558,9 @@ client-side failures (a tile that fails to start says so in the tile).
 - ProPresenter timers: `node tools/pp-timers-mock.js 1600` — running,
   overrunning, stopped and elapsed timers plus an LTC timecode that
   periodically drops to no-signal (`--no-ltc` serves a ProPresenter without
-  a timecode API). Point the Timers module at host `127.0.0.1`, port `1600`.
+  a timecode API). Also serves the stage-display websocket with an
+  LTC-labeled layout field (`--stage-pwd`, `--no-ltc-field` exercise its
+  failure paths). Point the Timers module at host `127.0.0.1`, port `1600`.
 - Planning Center: `node tools/pco-mock.js` (port 24700) — folders, service
   types, plans (last week / today / next week), plan times and items with
   songs, keys and item notes, behind a Basic/Bearer auth check. Planning