chore(jet): regenerate the backend jet to match the migrations

The committed go-jet code had drifted from the schema: robot_blocks and
robot_friend_requests (created in the baseline) had no generated tables, the
feedback_messages model was missing app_version/browser_tz (added in 00003 and
00004), and UseSchema omitted account_best_move and the two robot tables.
Regenerate so the jet layer mirrors the migrations again.

Additive only — two nullable columns appended to feedback_messages plus two new
tables; the full build, vet, unit and integration suites stay green.

PLAN.md

@@ -200,10 +200,11 @@ E2 flips reads and after Release 2). Reads still use the old columns until E2.
 ./backend/...` + `go vet` + `gofmt -l .` clean; committed `jet/payments/`; all tests green; no
 behaviour change for users.
 
-**Notes.** jetgen regenerates the whole `backend` schema; its committed jet was already drifted
-from the migrations (`robot_blocks`, `robot_friend_requests`, a `feedback_messages` column), so
-that churn was reverted and only `jet/payments/` committed — a pre-existing drift worth a separate
-cleanup. The `payments` role creation is idempotent (`DO $$` / `IF NOT EXISTS`) for fresh volumes.
+**Notes.** jetgen regenerates the whole `backend` schema; its committed jet had drifted from the
+migrations (`robot_blocks`, `robot_friend_requests`, the `feedback_messages` `app_version` /
+`browser_tz` columns, and `UseSchema` gaps), so this change also **regenerates and commits
+`jet/backend`** to bring it back in sync (additive only — all suites stay green). The `payments`
+role creation is idempotent (`DO $$` / `IF NOT EXISTS`) for fresh volumes.
 
 ---