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>

README.md

@@ -403,10 +403,23 @@ below. Nothing is installed without someone clicking.
   and part, as in `260927 Where is Your Faith? - Part 6` — is taken as the
   message and lands on the plan's message item (an item titled Message,
   Sermon or Teaching, else the first item under such a header). Admin
-  config is the connection: Planning
-  Center credentials (Personal Access Token app ID + secret, or an OAuth
-  token), the service type (a list grouped by your Planning Center folders)
-  and an optional pinned plan. Everything about the display is per tile
+  config is the connection: Planning Center credentials (Personal Access
+  Token app ID + secret, or an OAuth token), the service types to follow (a
+  list grouped by your Planning Center folders) and an optional pinned plan.
+  **Tick as many service types as you like** — the module follows whichever
+  of them has a plan soonest, so a campus running Sunday mornings, a
+  Wednesday night and a youth service needs one dashboard, not three. The
+  ticked types are **numbered in priority order**, nudged up and down with
+  the arrows beside them, and that order decides the winner when two of them
+  have a plan at the same date and time. Every tile's title bar then carries
+  a **service-type control** for reading one of the others: pick a type and
+  every PCO Plan tile on *that* browser's dashboard — plan, teams and song
+  key together — moves to its plan, marked with an amber stripe, while the
+  machine goes on following the live one. The choice is that browser's
+  alone, it sticks until changed, and the control hides itself when only one
+  service type is ticked. Live machinery belongs to the followed type:
+  another type's plan shows its running order without the now marker, the
+  service clock or AbleSet. Everything about the display is per tile
   (gear menu): the top-bar text (placeholders such as
   `{series} • {part} | {serviceType} • {date}`), colors, text size, and a
   show/hide checklist for every detail.