Tickets: settings, category edit and ticket list from Discord; NOTIFY triggers in schema.sql

- /tickets settings (on or off, panel title and text, open tickets per member), /tickets category edit, /tickets list
- schema.sql now creates the NOTIFY triggers, so the integration tests run on a database built from it, and two stale expectations (tickets start off) are fixed

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

docs/database.md

@@ -8,22 +8,7 @@ The bot uses PostgreSQL through `database/sql` with the pgx driver. All SQL live
 
 The hosted Velox also has a proprietary dashboard API that keeps its own migrations for the same tables. That is the maintainer's concern: if your change adds or alters a table, update `schema.sql` and say so in your pull request, and the maintainer ports it. You never need the API to develop or run the bot.
 
-Two things are not in `schema.sql`, because only a dashboard needs them: the `NOTIFY` triggers on the three `*_commands` tables (see below), and a migration history. If you write a tool that inserts command rows, add the trigger yourself:
-
-```sql
-CREATE OR REPLACE FUNCTION notify_music_command() RETURNS TRIGGER AS $$
-BEGIN
-    PERFORM pg_notify('music_commands', NEW.id::text);
-    RETURN NEW;
-END;
-$$ LANGUAGE plpgsql;
-
-CREATE TRIGGER music_commands_notify
-AFTER INSERT ON music_commands
-FOR EACH ROW EXECUTE FUNCTION notify_music_command();
-```
-
-The same works for `ticket_commands` and `security_commands`. Without the trigger the bot still picks the rows up, but only the next time it starts or is notified for another reason.
+`schema.sql` also creates the `NOTIFY` triggers on the three `*_commands` tables (see [below](#dashboard-to-bot-settings-and-requests)), so anything that inserts a request wakes the bot, with no `NOTIFY` of its own.
 
 ## Tables