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/development.md

@@ -154,7 +154,7 @@ Never trust the contents of a custom ID. A user cannot edit it, but old messages
 
 The usual path is table, repo, service, command. The meeting-room lobbies are a complete small example (`/meeting add-lobby`).
 
-**1. The table.** Add it to `schema.sql`, and to an API migration if the dashboard will show it (see [Database](database.md#changing-the-schema)).
+**1. The table.** Add it to `schema.sql` (see [Database](database.md#changing-the-schema)).
 
 **2. The repo**, in `internal/db/repos/<area>repo/repo.go`. SQL only, returning plain Go values:
 
@@ -188,7 +188,7 @@ if services.Global == nil || services.Global.Meeting == nil {
 added, err := services.Global.Meeting.AddLobby(ctx, guildID, channelID)
 ```
 
-**6. Enforce limits in the database when you can.** The 10-lobby limit is a trigger, so the bot and the dashboard cannot disagree and two simultaneous requests cannot both slip through.
+**6. Enforce limits in the database when you can.** The 10-lobby limit is a trigger, so the bot and anything else writing to the table cannot disagree and two simultaneous requests cannot both slip through.
 
 **7. Default to off.** A module that does something to a server without being asked (posts messages, moderates, grants roles) must start disabled and be turned on by an admin.
 
@@ -244,7 +244,7 @@ Call it at the end of `bot.Start()`. Log errors instead of returning them, and m
 
 Never log a secret, and never put one in a message to a user.
 
-Use an environment variable for deployment settings (tokens, hosts). Settings an admin or owner should change at runtime belong in the database and on the dashboard instead. That is how the beta settings work.
+Use an environment variable for deployment settings (tokens, hosts). Settings an admin or owner should change at runtime belong in the database instead (set with a command, or by a dashboard). That is how the beta settings work.
 
 ## Make a command beta
 
@@ -281,7 +281,7 @@ Good things to test: permission checks (does the wrong person get refused?), lim
 - **One feature per package, SQL only in repos, rules in services.** Commands never contain SQL.
 - **Match the code around you**: naming, comment density, error handling. Comments explain *why*, not *what*.
 - **Fail closed.** If you cannot tell whether someone is allowed, they are not.
-- **Validate everything that comes from a user or the dashboard**: option values, custom IDs, `payload` JSON in command rows.
+- **Validate everything that comes from a user or from another program writing to the database**: option values, custom IDs, `payload` JSON in command rows.
 - **Escape user text** in messages, and set `AllowedMentions` so it cannot ping.
 - **Bound everything per server**: caches, lists, loops. One server must not be able to use unlimited memory.
 - **Do not leak internals** to users: reply with a short message, log the detail.
@@ -292,7 +292,7 @@ Good things to test: permission checks (does the wrong person get refused?), lim
 
 - [ ] `gofmt` on the files you touched, `go build ./...`, `go vet ./...`, `go test -race ./...`
 - [ ] Commands: in `AllCommands` and `handlers`, permission check in the handler, ephemeral errors
-- [ ] New table: in `schema.sql` **and** in an API migration, with a note about deploy order
+- [ ] New table or column: in `schema.sql`, and mentioned in the pull request
 - [ ] Module that acts on a server: off by default
 - [ ] `/help`, [Command reference](commands.md) and [Features](features.md) updated
 - [ ] No secrets, tokens or personal IDs in code, logs or tests