Make the snooze presets configurable (morning hour, evening hour, quick offsets)

[Ashkaan]

Problem

The five snooze presets are hardcoded. resolveSnoozePresets(now) in packages/client-runtime/src/state/threadSettled.ts takes only the current time — there is no settings input — and the wake times come from three module constants:

const HOUR_MS = 60 * 60 * 1_000;
const EVENING_HOUR = 18;
const MORNING_HOUR = 9;

So "This evening" is always 18:00, "Tomorrow" and "Next week" are always 09:00, and the two relative presets are always +1h and +3h.

Those are reasonable defaults, but they are a guess about someone's day. If your day starts at 07:00, "Tomorrow" wakes every thread two hours after you needed it. If you work until 20:00, "This evening" fires mid-afternoon while you are still in the thread it woke. Snoozing is a per-thread action you take many times a day, so a preset that is two hours off is two hours off every single time — and the only workaround today is to stop using the preset.

Proposal

Let the preset times come from settings, keeping the menu itself exactly as it is:

• Morning hour (drives Tomorrow and Next week) — default 9
• Evening hour (drives This evening) — default 18
• The two quick offsets (In 1 hour / In 3 hours) — default 1h and 3h

The labels should stay derived from the configured values, which they already are: whenLabel is formatted from the resolved Date, so a 07:00 morning hour renders "Tomorrow — 7:00 AM" with no extra work. The same is true of the two rules that hide a preset — "This evening" only appears while it is more than an hour out, and "Next week" collapses when it lands on the same instant as "Tomorrow" (the Sunday case from #8740). Both compare resolved times rather than constants, so they keep working against configured values without changes.

The preset ids are already a closed union:

export type SnoozePresetId = "hour" | "three-hours" | "evening" | "tomorrow" | "next-week";

which gives config a stable key per preset without inventing new identity for them.

Scope

This looks client-side only. thread.snooze already accepts an arbitrary ISO snoozedUntil and the server already validates it, so no protocol, persistence, or server change is implied. Because presets resolve in shared client-runtime, threading settings into resolveSnoozePresets should reach web, desktop, iOS, and Android from one place.

Relationship to the custom-time proposals

This is not #11210 (and not PR #6082), and neither one subsumes the other:

• A custom date/time picker answers "this particular thread, until Friday at 14:30" — an exception, chosen per snooze.
• Configurable presets answer "my morning is 07:00, always" — the default, chosen once.

Someone whose morning is 07:00 does not want to open a picker every time they snooze a thread to tomorrow. The two features complement each other, and configurable presets are the smaller change of the two.

---

Prepared by Claude Opus 5 on behalf of @Ashkaan, from a read of threadSettled.ts on main (client 0.0.40).