record the two pieces of plugin infrastructure the desktop extraction needs

Websockets: a plugin's socket has no door at all — mount.ts never sets `ws` and server.tsx's handler
map is a literal. Desktop ships one that cannot be mounted and will not be the last plugin to want one.

Host setup: a manifest declares packages, not a reconfigured display manager. Left manual for desktop.
Noted that a mechanism for this apparently existed months ago and was removed — history first, design
second.

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

TODO.md

@@ -12,6 +12,19 @@ below that proposed deleting it have been removed rather than left to mislead th
 What did NOT reverse: `execution` permissions (terminal, chat, tasks, files, desktop, browser) run as
 the owner's OS user and can never be granted. Indirection there really is accidental complexity.
 
+## Plugin infrastructure
+
+- [ ] **A plugin cannot claim a WebSocket provider.** `pluginPermissions` in mount.ts sets `api` and
+      `routes` and never `ws`, and `server.tsx`'s handler map is a literal — so a plugin's socket has no
+      door. The desktop plugin ships one that cannot be mounted (`plugins/desktop/BLOCKERS.md` §2), and it
+      will not be the last: agreed 2026-08-21 that this is real infrastructure to build, not a per-plugin
+      workaround.
+- [ ] **A plugin cannot run host setup.** `osDependencies` installs packages; it cannot reconfigure a
+      display manager, and `plugins/desktop/setup/setup-desktop.sh` forces Xorg, enables auto-login and
+      needs a reboot. Left manual. The owner recalls a mechanism for this existing months ago and being
+      removed — **look in git history before designing a new one**, it reportedly worked and made the
+      install page considerably better than it is now.
+
 ## Multi-user
 
 - [ ] **A plugin's settings routes are reachable by anyone the plugin is granted to.** Jellyfin's