-- Ein eigenes Schreibbudget je Projekt.
--
-- ── Warum? ───────────────────────────────────────────────────────────────────
--
-- Ein gültiger API-Key umgeht die IP-Sperre bewusst (siehe APIAuth in
-- internal/web/middleware.go). Damit hat ein Agent, der in einer Schleife hängt,
-- überhaupt keine Grenze mehr — er schreibt, bis die Platte voll ist.
--
-- Die Obergrenze hängt am Projekt und nicht am Key: Ein Limit je Key ließe sich
-- umgehen, indem man einen zweiten Key anlegt, und das darf jeder Projekt-Admin
-- selbst.
--
-- ── Warum die Vorgabe 0 und nicht die eigentliche Zahl? ──────────────────────
--
-- 0 heißt hier nicht "darf nicht schreiben", sondern "keine eigene Angabe —
-- es gilt der Standard aus WRITE_LIMIT_HOURLY". Damit muss diese Migration
-- keine Daten anfassen: Alle bestehenden Projekte bekommen automatisch den
-- Standardwert, und der lässt sich später in der Umgebung ändern, ohne jede
-- Zeile nachzuziehen.
--
-- Die eigentliche Zahl steht bewusst NICHT als Vorgabewert im Schema. Sonst
-- gäbe es zwei Orte, an denen ein Standard festgelegt ist, und irgendwann
-- widersprechen sie sich.

-- ALTER TABLE ... ADD COLUMN können SQLite und PostgreSQL gleichermaßen.
ALTER TABLE projects ADD COLUMN write_limit_hourly INTEGER NOT NULL DEFAULT 0;