music becomes a plugin, and the player stays behind

The whole of music moves to plugins/music/: the sidecar (index, indexer,
stream-audio, nightly-reindex), the four Postgres tables and their queries,
the /music workspace panels, MUSIC_API.md and the reindex CLI. The platform
keeps no music routes, no music capability entry, no music screen and no
music schema.

Three things stayed, each on purpose.

cliamp and the widget were out of scope by the owner's decision. The plugin's
sidecar still serves the two cliamp sockets, so it imports cliamp-ws.ts and
pulse-audio.ts from @@/sidecar/music/ — the files stay where they were.

The player did not move, and that was the open judgement call. Deciding it
took one fact: the dashboard widget imports useMusicPlayer and PlayerTrack
from officerdev, and the platform cannot import from a plugin. So the player
STATE stays whatever is decided about the UI around it, and two copies would
mean two audio engines. Given that, the engine and the bar stayed with the
state rather than being split from the thing they drive. Moving them would
also have needed a shell slot rendering a plugin-provided component on every
route — the one escape hatch this system deleted on purpose. MusicPlayerHost
gates on can('music'), which is now the plugin's permission, so the seam
switches itself off with the plugin.

api/music/router.ts stays too: api/cliamp/relay.ts imports getMusicServerWsUrl
from it. The plugin's api/router.ts re-exports that proxy rather than building
a second one — two subscribers to the one-shot music:server port announcement
would work today and 503 on the first reconnect where only one was listening.

Two bugs found on the way, neither visible from reading.

The app-store catalogue still listed music. Availability is derived from
sidecar_installs and a PLUGIN never gets a row there, so `music` would have
been permanently unavailable — which puts /music into deniedRoutes and blanks
the screen on a server where the plugin was installed and healthy. Exactly
the headscale bug documented six lines above it in the same file, and it would
have fired on the first install. Entry removed.

[test] root was "./src", so moving lyrics.test.ts into plugins/ stopped it
running and said nothing — the count fell by nine and the suite still read
green. Root is now the repo. Positional filters cannot fix this: `bun test
plugins` matches under root and finds src/servers/plugins/ instead.

registry.test.ts tested the `personal` mechanism THROUGH the music capability.
Re-anchored on a fixture rather than on another entry, because borrowing a
feature only moves the problem to the next extraction — and three of those
four tests had been passing for the wrong reason since music's api was
commented out on 2026-08-13, when everything started resolving to "refused
because nothing is claimed". The cliamp sockets being claimed by nothing is
now pinned by a test instead of being rediscovered.

music's `personal` paths ride across on readOnlyWrites, the one field a
manifest has. isRequestAllowedAtLevel concatenates the two lists, so a read
grant permits exactly the four paths it permitted yesterday, and no field was
added to the manifest to design a per-user model that is not this work.

bunx tsgo clean. 772 tests, 762 pass, 7 fail — all seven pre-existing and
unrelated (cliamp, pty, and five capability tests that other switched-off
plugins break). Baseline was 757/10; the three that went green are the ones
re-anchored above.

Not yet verified on the live server — that is next.

plugins/music/manifest.ts

@@ -0,0 +1,85 @@
+import type { PluginManifest } from '@@/plugins/manifest';
+
+// Music — the library, the player, and the phone and tablet apps that stream from it.
+//
+// The second plugin extracted from the platform, on 2026-08-15. Bigger than offscale and, unlike it, not
+// a clean cut: three pieces stay behind deliberately. Each is a documented seam rather than a loose end,
+// and each is recorded in ./PLUGIN.md with what would have to change to close it.
+//
+//   api/router.ts     re-exports the platform's music proxy — see that file for why it is not a new one
+//   sidecar/          the whole /api/music contract: indexing, streaming, per-user state
+//   db/               music_favorites, _playlists, _playlist_items, _now_playing
+//   web/              the library panels; the shell renders the Workspace
+//
+// ── What stayed in the platform, and why ──
+//
+// 1. cliamp (`/api/cliamp/ws`, `/api/cliamp/audio/ws`, `sidecar/music/cliamp-ws.ts`, `pulse-audio.ts`,
+//    `asoundrc`). A second playback path — the `cliamp` TUI run on the server with its terminal and its
+//    PulseAudio null sink piped to the browser. Already inert (the routes upgrade into commented-out
+//    handlers) and out of scope by the owner's decision. This sidecar still serves those sockets, so it
+//    imports both modules from `@@/sidecar/music/`.
+//
+// 2. The dashboard widget (`src/workspaces/widgets/MusicPlayer/`). Plugins cannot contribute widgets and
+//    the mechanism was not worth inventing for one.
+//
+// 3. The global player overlay (`officerdev/src/MusicPlayer/`, mounted by `DashboardLayout`). This was
+//    the one open judgement call and it is decided: THE PLAYER STAYS IN THE PLATFORM. Two reasons, and
+//    the second is the one that settles it.
+//
+//    - Moving it needs a shell slot that renders a plugin-provided component on every route. That is
+//      exactly the escape hatch this system deleted on purpose — "there is no way to export a component"
+//      is what makes "every plugin route is a Workspace" a property of the shape rather than a rule
+//      someone has to remember. Reopening it for one plugin is a bad trade.
+//    - It would not even work. The widget above imports `useMusicPlayer` and `PlayerTrack` from
+//      `officerdev`, and the platform cannot import from a plugin — so the player STATE stays whatever
+//      is decided about the UI. Splitting the engine from the state it drives would leave the same seam
+//      in a worse place, and two copies of that state would mean two engines.
+//
+//    The overlay gates on `can('music')`, which resolves against the permission below — registered at
+//    install and gone at uninstall. So the seam switches itself off with the plugin, with no code path
+//    that knows why.
+//
+// ── Host dependencies a manifest cannot declare ──
+//
+// `ffmpeg` and `ffprobe` must be on PATH: tag reading, cover compression and video poster frames. There
+// is no field for a host binary and inventing one for this would be a field nothing else reads.
+export const manifest: PluginManifest = {
+  publisher: 'officerdev',
+  version: '1.0.0',
+  platform: '>=1.0.0',
+
+  label: 'Music',
+  summary: 'The music library — browse, play, favourites and playlists',
+  icon: 'Music',
+  color: '#22c55e',
+
+  // One permission gating the whole surface, grantable per role at read or write like every other.
+  //
+  // The key is `music` and that is not incidental: it is the key the platform's own registry used until
+  // this extraction, so every existing `role_capabilities` grant keeps meaning what it meant, and the
+  // overlay's `can('music')` keeps resolving. Renaming it would have been a silent data change.
+  //
+  // `[open]` What a member's grant MEANS here is this plugin's own job and is not finished. Favourites,
+  // playlists and now-playing are already per-caller — the sidecar scopes every one of them by the
+  // `X-Officer-User` header the proxy injects — while the library itself is one shared index for the
+  // household. So "whose row is this" already has a real, non-uniform answer, which is why the platform's
+  // side of it is a uniform read/write and nothing more. Designing the rest belongs in these queries.
+  permissions: [
+    {
+      key: 'music',
+      label: 'Music',
+      description: 'The music library, playback, and your own favourites and playlists',
+      // These are the `personal` paths from the registry entry this replaces, carried across verbatim.
+      //
+      // They are not read-only — they are genuine writes to the CALLER'S own data, which is what made
+      // them safe at read level. The manifest deliberately has no `personal` field, and adding one would
+      // be designing the per-user visibility model that is explicitly not this extraction's work. It
+      // costs nothing to go without: `isRequestAllowedAtLevel` concatenates `personal` and
+      // `readOnlyWrites` into a single allow-list, so the two are the same mechanism under two names and
+      // a read grant permits exactly the same four paths it permitted yesterday.
+      //
+      // `/queue` is here because it was there. No such route exists, in the sidecar or anywhere else.
+      readOnlyWrites: ['/favorites', '/now-playing', '/playlists', '/queue'],
+    },
+  ],
+};