Fix business date rollover and make timezone a setting

[bradydibble]

Problem

The date field on /calculate was computed with new Date().toISOString() — i.e. in UTC. After ~5 PM Pacific (when UTC crosses midnight) the form defaulted to tomorrow's date. This is the reported bug: the site showed 7/14/26 while it was still 7/13/26 in Pacific.

Two things also needed fixing beyond raw timezone:

• The timezone was hardcoded — it's now a setting.
• A restaurant's business day shouldn't roll to the next date at midnight. Late-night close-outs belong to the day the shift started, so the date should not advance until after 3 AM local time.

Changes

• $lib/business-date.ts — new pure helpers:
  • businessDate(now, timeZone, rolloverHour = 3) → YYYY-MM-DD for the configured timezone, staying on the prior day until 3 AM local.
  • defaultShift(...) → Lunch/Dinner default; the post-midnight close-out window now defaults to Dinner.
  • isValidTimeZone(...), DEFAULT_TIMEZONE = 'America/Los_Angeles'.
• Timezone is now a setting (default America/Los_Angeles): seeded in db.ts, validated + persisted in settings/+page.server.ts, and selectable via a dropdown of common US zones in the Settings UI. The "Lunch Cutoff" label is no longer hardcoded to "Pacific".
• calculate/+page.server.ts uses the helpers with the configured timezone instead of UTC.
• business-date.test.ts — 19 tests: the reported bug, the 3 AM boundary (2:59 vs 3:00), closing time (1 AM stays prior day), month/year boundaries, spring-forward DST, and an alternate timezone.

Verification

• npm test (44 tests), npm run check (0 errors), npm run lint — all green.
• Drove the real app against the live clock (9 PM Pacific / next-day UTC): /calculate now defaults to the correct Pacific date, and switching the timezone setting to UTC flips it (proving the setting drives the computation), switching back restores it. Invalid timezones are rejected.

🤖 Generated with Claude Code