feat: Meal group assignment for checked-in hackers

[balebbae]

Summary

Add meal group support so 1200+ hackers can be split into staggered meal times during the event. Super admins configure named meal groups (e.g., "Group A" through "Group E") via a new setting. When a hacker is checked in via QR scan, they are randomly assigned to one of the configured groups permanently.

Approach

Database

• Add nullable meal_group TEXT column to applications table (migration 000023)

Settings (stored in settings table as JSONB)

• New meal_groups key storing a JSON array of group name strings
• Super admin endpoints: GET /superadmin/settings/meal-groups, PUT /superadmin/settings/meal-groups, GET /superadmin/settings/meal-groups/stats
• GET/PUT pattern (array replacement, consistent with saquestions and scan-types)

Assignment Logic

• On check-in scan (POST /admin/scans with check_in category), randomly pick a configured meal group and set it on the application
• Assignment is non-fatal — if it fails, the check-in still succeeds (logged as warning)

Scan Response Enhancement

• POST /admin/scans response now includes meal_group field
• On check-in: returns the newly assigned group
• On meal scans: looks up and returns the hacker's existing group
• Allows admins to see the hacker's meal group immediately after scanning

Stats

• GET /superadmin/settings/meal-groups/stats returns count of hackers per group (queries applications table directly)

Tasks

• Migration: add meal_group column to applications
• Store: settings methods (GetMealGroups, SetMealGroups, GetMealGroupStats)
• Store: application methods (SetMealGroup, GetMealGroupByUserID) + update existing queries to include meal_group
• Mock store updates
• Handlers: meal group settings (get, set, stats)
• Handler: modify createScanHandler for assignment + response
• Routes: register new endpoints in api.go
• Tests: settings handlers + scan handler meal group scenarios