[api] #29 fix player cheers

apps/api/migrations/0013_reputation.sql

@@ -23,10 +23,8 @@
 -- numbers that will have a source one day, so the column is here and turning them on later
 -- is a write rather than a migration.
 --
--- `IsCheerful` and `SelectedCheer` are NOT columns. They ride along on the DTO and the
--- `ReputationUpdate` frame, but nothing on this server varies them per player — they are
--- constants (true / 0) the projection fills in. A column defaulted to the same value for
--- everybody, that nothing ever writes, only invites a reader to believe it means something.
+-- `IsCheerful` and `SelectedCheer` were left off here on the theory that nothing varied
+-- them per player; 0014 adds them — `SelectedCheer` is written by `SetSelectedCheer`.
 
 CREATE TABLE IF NOT EXISTS reputation (
   account_id INTEGER PRIMARY KEY,

apps/api/migrations/0014_reputation_selected_cheer.sql

@@ -0,0 +1,12 @@
+-- The two profile fields 0013 left off the `reputation` table on the theory that nothing
+-- varied them per player. Owned by the `api` worker; generated from src/reputation-db.ts
+-- (SCHEMA_DDL) — keep in sync.
+--
+-- `selected_cheer` is the cheer a player has PINNED to their profile, written by
+-- `POST /api/PlayerCheer/v1/SetSelectedCheer` (form `CheerCategory`), which every reference
+-- server stores per player — 0013's "no endpoint sets one" was wrong. `is_cheerful` is the
+-- profile flag the client's DTO and `ReputationUpdate` frame both carry, read straight off
+-- the record like every reference does; it is a column so it can vary one day without a
+-- migration, defaulted true because that is what every reference serves.
+ALTER TABLE reputation ADD COLUMN is_cheerful INTEGER NOT NULL DEFAULT 1;
+ALTER TABLE reputation ADD COLUMN selected_cheer INTEGER NOT NULL DEFAULT 0;