Docs: say plainly that only the bot is open source; the dashboard and API are proprietary

- README, license section and architecture no longer point to the dashboard repositories
- schema.sql is the schema for contributors; database changes only need schema.sql and a note in the PR
- self-hosting: settings without a dashboard (SQL for security thresholds, beta settings, opted-in servers)
- beta features, deployment and troubleshooting reworded for people who don't have the dashboard

Co-Authored-By: Claude Sonnet 5.5 <[email protected]>

docs/architecture.md

@@ -19,7 +19,7 @@ This page explains how the bot is put together, so you know where to look and wh
         |                          |                           |
         +----------- services (rules) <------ repos (SQL) -----+
                                    |
-                              PostgreSQL  <---->  velox-dashboard-api  <---->  dashboard
+                              PostgreSQL  <---->  a dashboard (the hosted Velox has a proprietary one)
 ```
 
 The bot is one Go process. It keeps one websocket connection to Discord and one connection pool to PostgreSQL. It has no HTTP server of its own.
@@ -85,14 +85,14 @@ Some commands have a response that takes longer than three seconds (anything tha
 | Raid watch | `security` | 30 s | Ends raid mode after a quiet period |
 | Snapshots | `security` | 6 h | Saves roles and channels while anti-nuke is on (keeps three) |
 | Beta settings | `bot/bot.go` (`WatchBeta`) | 30 s | Re-reads who the beta testers are and which servers opted in, and adds or removes beta commands to match |
-| Command listeners | music, tickets, security | on `NOTIFY` | Carry out dashboard requests |
+| Command listeners | music, tickets, security | on `NOTIFY` | Carry out requests written to the `*_commands` tables |
 
-## The link to the dashboard
+## How a dashboard talks to the bot
 
-The bot and the dashboard API do not talk to each other directly. They meet in PostgreSQL, in two ways:
+The bot has no HTTP server and no API of its own. A web dashboard, such as the proprietary one the hosted Velox uses (not part of this repository), meets the bot in PostgreSQL, in two ways. This is the whole contract, so you can drive the bot the same way with SQL or write your own tool:
 
-1. **Settings tables.** The dashboard writes settings (log channel, security thresholds, ticket categories, beta role). The bot reads them when it needs them. Hot paths cache them for a short time, so a raid of thousands of joins does not become thousands of queries.
-2. **Command tables with `NOTIFY`.** When the dashboard needs the bot to *do* something (skip a song, post the ticket panel, release a quarantined member), it inserts a row in `music_commands`, `ticket_commands` or `security_commands` and issues `NOTIFY` on that channel. The bot has a long-lived connection that runs `LISTEN`, picks up the row, validates it again and carries it out. Never trust a row just because it is in the table: the listeners re-check permissions themselves.
+1. **Settings tables.** A dashboard writes settings (log channel, security thresholds, ticket categories, beta role). The bot reads them when it needs them. Hot paths cache them for a short time, so a raid of thousands of joins does not become thousands of queries.
+2. **Command tables with `NOTIFY`.** When a dashboard needs the bot to *do* something (skip a song, post the ticket panel, release a quarantined member), it inserts a row in `music_commands`, `ticket_commands` or `security_commands` and issues `NOTIFY` on that channel. The bot has a long-lived connection that runs `LISTEN`, picks up the row, validates it again and carries it out. Never trust a row just because it is in the table: the listeners re-check permissions themselves.
 
 Both directions are described table by table in [Database](database.md).