feat(chat): gate edit and delete on the server's message windows

[bmc08gt]

Stacked on #721 — review that first; the base is feat/user-flags-message-windows, not main.

What this does

UserFlags.messageEditWindow / messageDeleteWindow landed in #721 but nothing read them: ConversationLoadCoordinator passed MessagePolicy.default, which carried no windows, so Edit and Delete were offered on every confirmed message of your own regardless of age.

• MessagePolicy gains deleteWindow next to editWindow, and MessageCapability.resolve gates .delete on it the same way it already gated .edit. .delete was previously seeded unconditionally.
• MessagePolicy(userFlags:) builds the policy from the flags and applies the fallbacks. The call site passes it instead of .default.

Fallbacks

15 minutes for edit, 48 hours for delete, named as MessagePolicy.fallbackEditWindow / fallbackDeleteWindow so they are greppable and comparable against Android.

The fallback sits at policy construction, not in UserFlags.init(_:), so nil on the model keeps meaning "the server said nothing". Session.userFlags is optional and updateUserFlags() never assigns on failure, so optional-chaining collapses three cases into one expression: no flags yet, a failed fetch with no cached row, and flags whose window fields are unset. The failed-fetch case needs no separate path, and a test covers it alongside the present-but-unset case.

This inverts the reasoning the old doc comment recorded — it defaulted to nil because a client-side window would only hide an action the server would have accepted, and with a fallback in force that can now happen. The comment is rewritten to state the new rule and the trade-off: an affordance the server rejects is the worse failure, and both clients applying the same values matters more than matching server behaviour exactly.

The clock

map's comment named this as the hard part. now: message.date made elapsed time always zero, so a window could never lapse; reading Date.now inside map would make it impure and break the Inputs-equality short-circuit that lets an unrelated tick skip the remap and lets the snapshot cross to a background task.

now is carried in Inputs and advanced only by scheduleWindowExpiry, which asks MessageCapability.nextExpiry for the soonest deadline among the window's messages and sleeps until it, then advances the clock and re-maps. map stays pure and the short-circuit keeps working; the cost is that the clock is only as fresh as the last thing that advanced it, which is sound because every boundary crossing has a timer scheduled for it. The old comment is replaced with one describing this.

Details worth a look in review:

• Nothing polls. No expiring message means no timer at all, and each firing schedules only the next deadline.
• The timer wakes one second past the deadline. Firing exactly on it would still resolve the capability as granted (the boundary is inclusive) and then compute the same deadline again, so the row would never drop.
• Sleeps are clamped to an hour so a 48-hour delete window doesn't park a task behind a transcript nobody is reading. The cost is at most one extra remap per hour on a transcript left open that long.
• refresh(with:) is split out of observeInputs because the timer drives a re-map too and must not install a second observation arm.
• nextExpiry runs eligibility through resolve rather than re-deriving it, so a message with no windowed capability to lose contributes no deadline by construction.

Parity

Same fallback values, same treatment of unset windows, and <= at the boundary so a message at exactly the window length is still actionable — matching Android's MessageCapability.kt. No deliberate deviations.

Out of scope

No change to the server-side authority model or to CANNOT_EDIT / CANNOT_DELETE handling. Client-side affordance gating only.

Tests

MessageCapabilityTests covers both capabilities inside their windows, past them, at exactly the boundary and a hair past it, independent gating, nil windows, the fallback from absent and from present-but-unset flags, server-sent windows overriding the fallbacks, and the nextExpiry deadline selection.