Layouts keep every tile they are given, and show what is on offer

The bug behind this: for seventeen days the server rebuilt each saved tile
from the fields it knew and dropped the rest — including `variant`, so a
layout of five different timers came back from the server as five "All
timers". The client had carried `variant` since multi-tile modules arrived;
the server was the one that lagged, and it is the part of ProdDash that
always will (a booth updates weeks after the dev machine). So the server
stops deciding which tile fields exist: it checks the shape of the ones it
knows, keeps any other small plain-JSON field a tile carries, drops only
retired ones, stamps the file `v: 2`, and refuses a layout over a hundred
tiles instead of quietly saving the first hundred. A test round-trips a
fully-populated tile plus one the server has never heard of, and fails if
anything is lost.

Then the rule the arrangement is loaded by. A layout keeps every tile it is
given; the board shows the ones whose module is installed and enabled and —
for a tile added from a picker entry — whose entry is offered right now. The
rest keep their place and draw nothing, and appear the moment the registry
offers them again: a Service timer waits for PCO Plan, a transcript for its
channel. Never the module's default in their place. Because a module's entry
list can change with no event to mark it (PCO Plan comes back and, seconds
later, the timers module is offering its timers again), the registry is
re-read every few seconds while anything is folded away, and not at all
otherwise. The timers module's placeholder card for a missing solo timer
goes with this: nothing is drawn, the dot says why.

Loading says what it did — "Loaded 'FOH': 9 tiles, 2 not shown — Service,
#ops aren't offered right now" — with Undo in the message. Saving over a
name asks first, and the server keeps the copy it replaced one back; Admin →
Saved layouts gets Restore previous, which swaps the two so a restore is one
restore from undone. The browser keeps one good copy of its own layout
behind the live one and falls back to it when the live one will not parse.

Shell 1.8.0, timers 1.4.1. The layouts already saved on the booth machines
had their variants stripped before this and have to be saved again from a
browser that still holds the right tiles — nothing here recovers what the
files no longer contain.

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

docs/MODULE-GUIDE.md

@@ -592,10 +592,17 @@ module.exports = {
 - When the user adds an entry, its `settings` overlay your `instanceSchema`
   defaults in that tile's instance settings, the entry's `name` becomes the
   tile's title, and `moduleApi.variant` carries its `id`.
-- The tile keeps its variant id and title even if the entry later vanishes
-  from your list (a timer deleted in ProPresenter, a page removed in admin).
-  **Your client decides what that means** — show a clear "no longer
-  configured" state rather than erroring.
+- **A tile is shown only while its entry is offered.** The shell mounts a
+  tile added from an entry only when that entry (or one of its `aliases`) is
+  in your list right now; otherwise the tile keeps its place in the layout,
+  draws nothing, and appears the moment your list offers it again — a
+  Service timer waits for PCO Plan, a transcript for its channel. So your
+  client is never asked to render an entry you did not offer at mount time.
+  One case is still yours: an entry that vanishes *after* the tile mounted
+  (a timer deleted in ProPresenter mid-service). Render nothing for it — no
+  placeholder, no error — and the shell folds the tile away at its next
+  registry refresh. Never fall back to your default view in its place: five
+  different timers turning into five "All timers" is worse than five gaps.
 - A client-only module can declare a fixed list as a `tiles` array in
   `module.json` instead (same entry shape).
 - An empty list (or no `tiles` at all) keeps today's behavior: one picker