[SiteRelEnby]

Four front-history bugs from the docs pass. All reproduced against a live instance before fixing.

Deleting an entry failed under any auth tier. The delete was a bare DELETE with no body, and System Safety's tier guards every deletion whether or not Fronts is a ticked category, so the server answered 400 "Password required" and the screen showed "Delete failed" with nowhere to type. Confirmed with Fronts unticked. It now carries credentials and asks for them first, through the same sheet the sharing screens use. That sheet's copy was hardcoded to publishing, so it takes a title and rationale now, defaulting to what it already said; the other callers are all privacy raises and are untouched.

A queued deletion was treated as done. With a grace period the server answers 202 and keeps the entry, but the call returned nothing so the row was removed, then reappeared on the next load with nothing marking it. The row already knew how to render a pending delete, dimmed with a badge, so it mostly had to stop being removed. The confirmation also stops promising "cannot be undone" when the entry is going to be held instead.

Emptying the custom status did nothing. The sheet trims a blank status to null, the adapter omits null, and the server reads an absent field as "leave as-is". Adds clearCustomStatus next to the existing clearEndedAt, which is the same problem already solved one field up.

Every edit rewrote both timestamps. The pickers drop seconds and the sheet resent both times on every save, so a status-only edit rounded them to the minute. That adds edits you did not make to the entry's history on the web, and it breaks contiguous-front coalescing, which the server walks by strict equality between one entry's end and the next one's start. Reproduced: a status-only edit moved a member's fronting-since from 07:00 to 09:15. Edits now send only what changed, which also preserves the seconds, since an absent field leaves the stored value alone.

Checked on device end to end: the credentials sheet appears with delete-specific wording, a wrong password is reported without losing the dialog, and a queued deletion leaves the entry in place with its pending badge. Server-side, a status-only patch leaves ended_at at its exact sub-second value, and an explicit null clears a status where omitting it did not.