add sqlite to Dockerfile

TODO.md

@@ -38,24 +38,12 @@ Guards:
 - **Live `IsRep` check in the handler.** Chapter and department come from
   a live `GetUser`, but nothing checks whether the person is still a rep.
   Someone whose flag was removed can still trigger a full reconcile.
-- **Add `sqlite` to the Dockerfile runtime stage.** Inspecting `skips`,
-  `runs`, or `sync_state` currently means a rebuild or a throwaway
-  container mounted on the volume.
 
 ## 4. Before going live
 
 - **`VACUUM INTO` on a timer.** Volume snapshots of a live WAL database
   are not safe to restore. The skip log is the only thing here that
   cannot be regenerated.
-- **Turn off `DRY_RUN`, redeploy.**
-- **Backfill.** The webhook only fires when a rep is *newly* assigned the
-  role, so the existing 119 never trigger it. Run with `DRY_RUN` set
-  first and count the assignments in the log; expect roughly 2,300.
-
-      sqlite3 worker.db "SELECT id FROM people WHERE is_rep = 1;" | while read id; do
-        curl -s -o /dev/null -X POST "https://HOST/webhook?id=$id&s=$SECRET"
-        sleep 1
-      done
 
 ## 5. Deferred design decisions
 
@@ -64,9 +52,6 @@ Guards:
   their department's rep signed up also stay unassigned until something
   triggers that department again. Rep replacement was described as
   frequent, so this matters more than the member-churn case.
-- **Raise the fill-only consequence upstream.** The rule came from
-  outside the project. The concrete cost is now measurable: 14 reps at
-  three campuses will open the app to an empty list.
 - **Schema migrations.** `CREATE TABLE IF NOT EXISTS` does not add
   columns to an existing table. Changing the schema currently means
   deleting the database and re-syncing, which will not be an option in