Dashboard viewer session cannot reinstate a tile restored by a failed remove-tile rollback #350

Found while fixing the PR #344 review findings (pre-existing constraint, now reachable via a rare path).

src/dashboard/application/dashboard-viewer-session.ts — syncDocument drops a tile's runtime record the moment the tile is absent from the synced document and can never reinstate it later (its own comment: "unknown IDs are dropped — a membership change should rebuild the session, not sync").

With PR #344's rollback/rebase, one real (if rare) path can now re-add a previously-removed tile via syncDocument instead of a session rebuild: user deletes a tile (optimistic membership change published) → that commit fails (or null-aborts) → the rebase re-publishes committed truth, which still contains the tile. app.state/the committed workspace are correct, but the reinstated tile's runtime record is gone, so its DOM/results may not fully re-render until the route repaints.

The #344 tests deliberately avoid remove-tile in the overlapping-failure scenarios for this reason (they use update-placement). Fix direction: have the Dashboard route detect a membership-restoring rebase and rebuild the session (or teach syncDocument to reinstate known-from-document tiles).