fix(status): reopen a Today status as Today near 16:00

[loganj]

🤖

Summary

• When you set a status to clear "Today" and open the status editor again, the duration menu should still say Today. Near 16:00 local time it said 8 hours, and near 23:00 it said 1 hour.
• This also caused an intermittent failure in the WebKit browser test user-status.spec.mjs. The browser tests run in UTC, so any CI run that saved a status between about 15:58 and 16:02 UTC failed with Duration: 8 hours.
• The editor now picks the preset that matches the saved expiry most closely.

Details

• Statuses save only an expiry time, not the preset the user picked. When the editor reopens, it guesses the preset by comparing the expiry with each preset's deadline, allowing a difference of up to two minutes. Before, it took the first preset in the list that was within two minutes. Around 16:00, "8 hours from now" is also within two minutes of midnight, and "8 hours" comes before "Today" in the list.
• Now it takes the preset with the smallest difference. The preset the user actually picked is normally an exact or near-exact match, so it wins.
• A mix-up can still happen if two presets produce the same deadline to the second. For example, on Sunday "Today" and "This week" both end at midnight. In that case either label describes the saved expiry correctly.
• The new unit test in status-duration.test.ts covers 16:00 and 23:00. It fails on main with Expected "today", Received "28800".
• The browser failure was reproduced locally. The WebKit test ran with the browser clock at about 15:59: it fails on main with the same error seen in CI and passes with this change.

[wesbillman]

Star Lord — automated source review via Wes's account

No actionable findings in this change.

Reviewed head d5f07c9bef22b5fffc74a9316b0ac8e3e200687e against base/merge-base 76946a4a6dabec18fd208ef71dcd9c676d970592.

• Traced the nearest-deadline selection through the status editor's initialization and unchanged-expiry preservation, plus the status parsing/save path. On production integer-second timestamps, this retains the existing two-minute tolerance; exact ties preserve preset order, consistent with the documented limitation that the chosen preset is not persisted.
• Inspected the deterministic unit regression cases around the eight-hour and one-hour midnight overlaps, existing editor deadline-preservation coverage, and the unchanged browser reopen assertion. The change stays scoped to preset inference and its unit regression test.

Validation limits: source-only review; pinned source extracts verified and read-only git diff --check passed. No PR code, tests, builds, or app workflows were executed. The PR's reported fail-then-pass/WebKit results were not independently reproduced; CI and runtime acceptance were not assessed. This is a non-blocking COMMENT review, not approval or merge authorization.