PCO Plan 1.10.0: follow several service types in priority order, and read any of them from any dashboard

An account runs more than one service type — a Sunday morning, a Wednesday
night, a youth service, a second campus — and until now that meant one
ProdDash per type. The module now follows as many as are configured.

Admin picks them in priority order. Shell 1.12.0 gives `multiselect` an
`orderable: true` that stops being a ticklist: the picks sit in a numbered
list with a nudge either way and a remove, over a dropdown holding what is
left. Forty switches to read past is not a picker, and a ticklist cannot
carry an order anyway. The order is the setting — when two types have a plan
at the same date and time, the one higher up wins.

The server gathers candidate plans from every ticked type and tiers them:
today's plan first, then the next upcoming, then the most recent past, with
the configured order breaking a tie. A type that fails is skipped rather
than failing the read, unless it is an auth or rate-limit answer, which
belongs to the whole connection. The types not being followed are read on a
slower lane (45 s) into `state.others`, so they are there to look at without
a second connection.

Every tile's title bar carries a service-type control. Picking one moves
every PCO Plan tile on that browser's dashboard — plan, teams and song key
together — onto its plan, over a small page bus in `viewed-type.js`; the
choice is per browser and survives a reload. The control hides itself when
only one type is configured.

Live machinery stays with the type being followed: another type's plan shows
its running order with no now marker, no AbleSet and no service clock — it
shows that plan's own scheduled time instead, since borrowing the running
clock of a different service is exactly the misreading the amber top-bar
stripe exists to prevent.

Old configs carry `serviceTypeId`; it is read once into the new array and
saved, and plan pins still resolve bare, so nothing has to be re-entered.

`tools/pco-mock.js` takes `--types N` to pad the list out, for trying the
picker against an account with dozens of them.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

docs/MODULE-GUIDE.md

@@ -222,7 +222,9 @@ Both schemas map field names to specs:
   "help": "One line shown under the control",         // optional, admin config only
   "options": [ { "value": "a", "label": "A", "group": "Optgroup" }, … ],  // "select" only
   "optionsRoute": "/devices",                         // "select" only, admin config only
-  "optionsDependsOn": "<other key>"                   // with optionsRoute; see below
+  "optionsDependsOn": "<other key>",                  // with optionsRoute; see below
+  "orderable": true,                                  // "multiselect", admin config only
+  "addLabel": "Add a service type…"                   // with "orderable"; the dropdown's own line
 }
 ```
 
@@ -242,8 +244,22 @@ marked, so nothing is dropped behind anyone's back. In a tile's gear popover
 it also takes `columns` (2–4) and `allByDefault: true`: a tile that has never
 chosen shows every option on and saves nothing until someone flips one, so
 options that turn up later are on as well (give it no `default` then).
+A `multiselect` with **`orderable: true`** stops being a ticklist. It renders
+as a list built on purpose — the picks, numbered in their saved order, each
+with a nudge either way and a remove — over a dropdown (`addLabel` names it)
+holding everything not picked yet, `group` and all. The array is stored in
+that order, so a module can read it as a priority. It is for a setting whose
+ORDER means something, and it is also what to reach for when the list is long:
+an account with forty service types is forty switches to read past, but one
+dropdown and two picked rows. `pco-plan`'s service types are the worked
+example — several are followed, and when two of them have a plan at the same
+moment the one higher up wins. Admin config only; the tile gear's own
+multiselect ignores it.
+
 `select` and `multiselect` may use `optionsRoute` in `instanceSchema` too —
 the popover GETs `/api/modules/<id><optionsRoute>` like the admin page does.
+`optionsDependsOn` follows any field, not just a select: a multiselect hands
+its values over comma-joined.
 
 `template` (tile settings) is a text with placeholders, built by dragging or
 clicking the variables the module offers into it: `"variables": [ { "value":