macOS menu-bar launcher: run ProdDash, and own its permissions

A native Swift app (launcher/macos, ~2 MB, no dependencies) that starts,
stops and watches over the server from the menu bar — and holds the macOS
permissions its modules need.

The permissions are the point as much as the buttons are. macOS grants
privacy permissions to the application that owns a process, and a child
inherits its parent's identity, so with the server started from here node —
and the Timers module's ltc-capture — belong to this app bundle and the
microphone and local-network prompts are asked, and remembered, as ProdDash.
Started over SSH or from a launchd job there is nobody to ask: the permission
is silently absent rather than refused, which is the "endless zeroes" failure
ltc-listener.js warns about.

The shell was already built for a supervisor: with PRODDASH_LAUNCHER=1 it
exits 75 instead of respawning itself when the admin page applies an update,
which the launcher reads as a restart request rather than a fault. Crashes
get a backed-off restart (1s, 2s, 5s, 10s) and four in two minutes stops the
cycle. The server is spawned into its own process group, so stopping it also
stops anything it started — an orphaned ltc-capture would otherwise hold an
audio device indefinitely — and signals, a logout and Quit all stop it first.

- Menu bar: ProdDash's own 2x2 tile mark, its accent tile lit green while
  serving, amber mid-move, red when something needs a person. Start, stop,
  restart, open the dashboard or admin, open at login, quit.
- Window: status and both addresses, plus Log (also written to
  ~/Library/Logs/ProdDash, kept a week), Settings, and Permissions.
- The port is written to the data directory's proddash.json — ProdDash's own
  file — so the port set here holds however it is next started. Something
  already on the port is reported, and offered as a takeover when it answers
  like a ProdDash started another way.
- Modules declare what they need in their manifests ("permissions": [...],
  documented in docs/MODULE-GUIDE.md and ignored by the shell); the launcher
  lists exactly that, with each module's reason, asks for the microphone,
  and — since macOS reports nothing about local network access — offers a
  check that browses for services and tries every configured upstream.

Timers, ProdCom and ProPresenter modules declare their permissions (patch
bumps). Build with launcher/macos/build.sh; output is gitignored.

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

docs/MODULE-GUIDE.md

@@ -66,6 +66,9 @@ the app); its settings are kept for a later reinstall.
   "version": "1.0.0",
   "proddash": ">=1.1.0",
   "description": "One line shown in the Add-tile picker and the admin page",
+  "permissions": [
+    { "kind": "microphone", "reason": "Why this module needs it, in one line" }
+  ],
   "client": "client.js",
   "server": "server.js",
   "style": "style.css",
@@ -88,6 +91,7 @@ the app); its settings are kept for a later reinstall.
 | `version` | yes | Your module's version (`x.y.z`). Bump it on every change — the admin page offers updates when the repo's copy is newer than the installed one. |
 | `proddash` | yes | The ProdDash versions this module works with: `">=1.1.0"`, `"^1.1.0"`, `">=1.1.0 <2.0.0"`, or `"*"`. A module whose requirement the running shell doesn't meet is listed in the admin page but never loaded, and can't be installed from the catalog. |
 | `description` | no | Shown in the admin page / picker. |
+| `permissions` | no | What macOS must allow before this module can work — see **Permissions macOS has to grant**. Ignored by the shell; read by the macOS launcher. |
 | `client` | yes | Client entry file, loaded as an ES module. |
 | `server` | no | Server entry file (CommonJS), loaded with `require()`. |
 | `style` | no | A stylesheet the shell injects once per module. |
@@ -207,6 +211,38 @@ Admin config lives in `modules.json` inside the server's data directory
 survives updates of the app folder). Per-tile settings live inside each
 browser's layout.
 
+### Permissions macOS has to grant
+
+Some things a module does need the operating system's permission, not just
+configuration: reading an audio input, reaching gear on the local network.
+macOS grants those to the **application that owns the process**, which for
+ProdDash is the macOS launcher (`launcher/macos`) — the server is its child,
+so the prompts are asked, and remembered, in ProdDash's name. A server
+started over SSH or from a bare launchd job has no such owner, and the
+permission is silently absent rather than refused: an LTC input reads as
+endless zeroes, a local host simply never answers.
+
+Declare what you need, and why, so the launcher's Permissions tab can list
+it and ask for it before a service rather than during one:
+
+```json
+"permissions": [
+  { "kind": "microphone",    "reason": "Decoding SMPTE LTC timecode from an audio input on this machine" },
+  { "kind": "local-network", "reason": "Reaching ProPresenter on this network" }
+]
+```
+
+| `kind` | When to declare it |
+| --- | --- |
+| `microphone` | The module reads an audio input (`ltc-capture` and anything like it). |
+| `local-network` | The module talks to gear on this building's network. Not needed for services out on the internet — Planning Center, say. |
+
+`reason` is one line, shown to the operator as-is; modules giving the same
+reason are listed together. A bare `"permissions": ["microphone"]` works when
+the standing explanation is enough. A `kind` the launcher doesn't manage is
+still listed, so nothing goes unmentioned — the shell itself ignores the key
+entirely, and other platforms ignore it too.
+
 ## Client entry (`client.js`)
 
 An ES module whose **default export is a factory**. The shell calls it once