the site sections open, because there is finally something behind them

`ready` was hardcoded false for as long as the sections proxied to an address
nobody could set — the connection form was removed and nothing replaced it, so
nine doors led to the same "not connected" message.

Both halves exist now and neither is typed by a person: the development server
runs on a port this plugin chose, holding a FOFOS_API_TOKEN this plugin
generated and handed it at start. So the credentials are DERIVED rather than
stored. Asking somebody to copy a value out of one part of this plugin into
another was never a setting, it was a chore.

Development and not production, and that is not a preference. Production is a
directory of files behind nginx — no API, no database, nothing listening — so
editing against it is impossible rather than merely wrong. Sections read and
write dev; Build is what publishes. An edit is visible immediately and public
only when somebody decides it should be.

The gate asks whether the server ANSWERS, not whether pm2 says online. `bun
--hot` survives a crash at startup: the process stays up, pm2 reports online,
and nothing is listening. Opening nine sections onto that would make one failed
boot look like nine broken screens.

And when /status itself cannot be reached, `configured` stays true while `ready`
goes false. Telling somebody they have set nothing up is alarming and wrong;
opening nine sections onto a server we could not confirm is answering is nine
screens that each fail separately. Cannot-tell keeps them shut and lets the next
poll open them.

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

api/router.ts

@@ -539,10 +539,26 @@ router.get('/status', async (ctx) => {
     that answer. The path itself stays behind `/_config`, which is owner-only — this says only whether
     one has been chosen, which reveals nothing about the machine.
   */
+  /*
+    `ready` is whether the site sections can be OPENED, and it is now answerable.
+
+    It was hardcoded false for as long as there was nothing behind them: the sections proxy to the
+    site's admin API, and no address for one was ever stored. Both halves exist now — the development
+    server runs on a port this plugin chose, holding a token this plugin generated — so the question
+    became a real one and this is the answer.
+
+    It asks whether the server is ANSWERING, not whether pm2 says online. `bun --hot` survives a crash
+    at startup: the process stays up, pm2 reports online, and nothing is listening. Opening nine
+    sections onto that would make one failed boot look like nine broken screens.
+  */
+  const servers = await readServers();
+  const development = servers.find((server) => server.name === 'development');
+
   return ctx.json({
     configured: connection.configured,
     lastProbeOk: connection.lastProbeOk,
     rootSet: settings.isSet,
+    ready: development?.reachable === true,
   });
 });