Demo: migrations follow the schedule, worked by a simulated team

Each device now migrates on the day of its date tag instead of on a
looping 24-hour clock: earlier days are finished, today's devices go
through backup and restore during working hours, later days haven't
started. The few that don't finish have a cause the dashboard shows
(broken client, broken WMI, low disk, a USMT error, unreachable PC).

A simulated team keeps two weeks of working days tagged. During working
hours it adds devices, reschedules or drops one, tags stuck PCs with
their problem, then fixes them and moves them to a new day; each morning
finished days are closed out and a new day is scheduled. Actions print
in the worker terminal as [Team] lines. Settings live in Demo.Team.

The visitor sandbox now keeps per-tag edits laid over the live roster,
so the team's changes keep showing around a visitor's own edits.

Overview calendar: today is a filled badge on the date number, so it no
longer looks like the selected day (outline plus tint).

README.md

@@ -141,15 +141,22 @@ without letting strangers change what other visitors see.
   `USMT-Worker.ps1` under PowerShell 7 with `-Demo`. The worker loads `Providers\Demo.ps1`
   instead of `Providers\SCCM.ps1`, and that's the only difference.
 - **A believable fleet.** The demo provider derives each device's hardware, users, location,
-  department and software from a hash of its name. Each migration moves through every stage
-  on a 24-hour clock, so the dashboard keeps changing. Devices go offline, have stale DNS,
-  run low on disk, and fail backups at realistic rates.
+  department and software from a hash of its name. Each device migrates on the day of its date
+  tag: earlier days are finished, today's devices move through backup and restore during
+  working hours, and later days haven't started. The few that don't finish have a reason the
+  dashboard shows: a broken ConfigMgr client, broken WMI, low disk space, a USMT error, or a
+  PC nobody can reach.
+- **A simulated team.** The next two weeks of working days are tagged, like a team working a
+  two-week schedule. During working hours someone adds devices, reschedules or drops one,
+  tags a stuck PC with its problem (*Bad Client*, *Low Disk Space*...) and later fixes it and
+  moves it to a new day. Each morning finished days are closed out and a new day is scheduled
+  at the end. Every action prints in the worker terminal as `[Team] ...`.
 - **Read-only API.** In demo mode the server refuses every route that writes (and
   `get-software`, which takes free-text input) with `403`. The terminal output is the real
   console of both processes, mirrored to `Data\Logs` by a `Write-Host` proxy.
 - **Visitor changes stay in their browser.** `web\demo\demo.js` intercepts the dashboard's
-  write requests and keeps the visitor's tags, articles and images in IndexedDB, merged over
-  the server's data. Their actions print in the terminal panel exactly as the services would,
+  write requests and keeps the visitor's tags, articles and images in IndexedDB, laid over
+  the server's data (so the team's changes keep showing up around them). Their actions print in the terminal panel exactly as the services would,
   marked with a small dot. Nobody else sees them, and nothing a visitor types reaches the
   server, so there's nothing to moderate or inject. **DEMO > Reset my changes** clears it.
 
@@ -168,9 +175,8 @@ On **Coolify**, create a resource from this repository using the *Dockerfile* (o
 Compose*) build pack, set the exposed port to **8080**, and attach a domain. The container
 reseeds the simulated fleet on every start and needs no volumes or secrets. Times are shown in
 `TZ` (default `America/Chicago`); set it to your own timezone. The demo worker runs
-6 AM to 9 PM every day (`Demo.BusinessHours` in the config) and sleeps overnight.
-The date tags (such as `10/7`) move along each day, so a container that runs for weeks still
-shows this week's deployments.
+6 AM to 9 PM every day (`Demo.BusinessHours` in the config) and sleeps overnight; the
+simulated team works 7:30 AM to 5 PM on weekdays (`Demo.Team`), so migrations run then.
 
 ### Demo (local PowerShell 7)
 
@@ -215,6 +221,7 @@ most likely to change:
 | `SCCM.Monitors` | `v_GS_WMIMONITORID` | Attached monitors (needs WmiMonitorID in hardware inventory) |
 | `Demo.BusinessHours` | 06:00-21:00, every day | When the demo worker runs |
 | `Demo.DeviceCount` / `CycleSeconds` | `200` / `45` | Size of the simulated fleet and its cycle pause |
+| `Demo.Team` | 07:30-17:00, Mon-Fri; 10 days ahead, 3 kept; 12 per day; an action every 4-12 min | The simulated team's hours, schedule window and pace |
 
 ### Adapting it to a different toolset