Weekly availability rows can freeze a wrong utcOffsetMinutes (UTC−3 found on an IST consultant) — audit + pin the launch rule

[teetangh]

What was found

While diagnosing #1320 against the live rows, every SlotOfAvailabilityWeekly row for consultant profile 263449b4-f7f2-4489-b100-dc5d3e6efe0a carries utcOffsetMinutes = -180 (UTC−3), not the +330 an IST consultant should have. startTimeUtc / endTimeUtc are absolute UTC minutes, so display and the #1320 fix are unaffected, but isMinuteWithinWeeklySlot (utils/slotAllocation/slotTimeUtils.ts:385-387) uses the offset for its day-shift math, and the allocator's getNextOccurrenceWeekly / matchWeeklySlotToDay read it too.

Where it is written

• app/api/user/consultants/[id]/route.ts:395-397 and app/api/slots/availability/weekly/route.ts derive the offset from User.timezone via getTimezoneOffsetMinutes, defaulting to 330 only when the timezone is missing, not when it is wrong.
• utils/onboarding-server.ts:141 derives it from the timezone passed at onboarding, defaulting to 0.

A browser or device reporting a wrong zone at onboarding time (or a seeded User.timezone) therefore freezes a wrong offset onto every row, and nothing re-derives it later.

Ask

1. Audit how many consultants carry an offset that disagrees with User.timezone (read-only SELECT; there is one Supabase project behind dev and prod).
2. Decide the rule for launch (IST-only per ADR 17): either pin utcOffsetMinutes = 330 on write regardless of the reported zone, or re-derive from User.timezone and reject a save whose offset contradicts it.
3. Add a regression test that the three write paths agree on the offset they store.

Follow-up from #1320. Part of #1319. Related: #872 (the post-MVP IANA model replaces the frozen offset entirely).