a Servers section: development and production, both under pm2

pm2 for BOTH, development included. A `bun dev` started in a terminal dies with
the terminal, and nobody can tell whether it is running without finding the
window it was started in. Under pm2 the two are the same kind of thing — a named
process with a status, an uptime and a log, startable from here and inspectable
from anywhere. The cost is that development stops printing to a console somebody
is watching, which is what `pm2 logs fofos-dev` is for; the process names are in
the panel so nobody has to guess them.

This plugin owns exactly two names, `fofos-dev` and `fofos-prod`, and every
command is built from that pair and from nothing a caller supplies. No request
can stop, restart or delete another process on the machine. That matters more
than usual here: Officer's own processes share this pm2 daemon, and a plugin
able to name any of them would be a way to take the host down through a web
form.

Start is really a replace — delete, then start. Not `restart`: it fails on a
process that has never existed, and on one that has it reuses the environment it
was started with, so a port or database changed here would be saved, displayed,
and not in effect. That is an hour of somebody's debugging.

The environment is assembled here because this plugin is what knows the ports
and the database names, and it is handed to pm2 through the invoking command's
own environment — pm2 has no flag for it; `--env` names a block in an ecosystem
file. The site reads .env files first and the environment last, so this fills
what is absent rather than overriding what somebody wrote down.

Ports have no default. It is the one setting where a plausible guess is worst:
it binds, the site appears to work, and it is quietly answering on a port
another service wanted.

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

web/sections.ts

@@ -1,5 +1,5 @@
 import type { LucideIcon } from 'lucide-react';
-import { Home, Info, Layers, Images, Handshake, Sparkles, Wrench, Settings, Mail, Cog, FolderOpen } from 'lucide-react';
+import { Home, Info, Layers, Images, Handshake, Sparkles, Wrench, Settings, Mail, Cog, FolderOpen, Server } from 'lucide-react';
 
 /**
  * The sections of the fofos admin, in nav order.
@@ -29,6 +29,7 @@ import { Home, Info, Layers, Images, Handshake, Sparkles, Wrench, Settings, Mail
 
 export type SectionKey =
   | 'administration'
+  | 'servers'
   | 'media'
   | 'messages'
   | 'site'
@@ -177,6 +178,27 @@ export const SECTIONS: Section[] = [
     // Pinned beside Administration: both are about this machine rather than about the site's pages.
     pinned: true,
   },
+  {
+    /*
+      The two processes that serve the site, under pm2.
+
+      Beside Administration and above it, because it is the same KIND of thing — this machine rather
+      than the site's content — but it is the one somebody opens most: whether the site is up is a
+      question with a different urgency from where its files are.
+
+      `requires: 'root'`, not a connection. It needs the checkout to run, and nothing from fofos itself:
+      a site that is down is exactly when its API cannot be reached, which is precisely when this has to
+      keep working.
+    */
+    key: 'servers',
+    label: 'Servers',
+    icon: Server,
+    hint: 'Development and production, and whether they are up',
+    path: null,
+    built: true,
+    requires: 'root',
+    pinned: true,
+  },
   {
     /*
       Last, and `path: null` — it reads nothing from fofos. Every other section is a window onto the