feat(ui): mark entities queued for deletion across every list

[SiteRelEnby]

Closes #50.

System Safety queues destructive actions behind a grace period rather than doing them immediately, so an entity can sit in a list looking perfectly alive while already scheduled for deletion. Home's banner said the system had pending actions; nothing said which rows.

What you see

A dimmed row plus a badge - "Deletes in 18h" - wherever a deletable thing is listed:

	list	detail
Members	People > Members	member profile
Groups	People > Groups	group detail
Front history	History	-
Journals	Journals	journal detail
Board messages	board detail	-
Polls	Polls	poll detail
Reminders	Reminders	-
Tags	Settings > System > Tags	-
Custom fields	Settings > System > Custom Fields	-
Notification channels	Notifications > Channels you own	-

Detail screens are marked too, so the state survives the tap that opens them - otherwise a dimmed row leads to a page that looks fine.

Why the models were the bulk of it

Only NotificationChannelRead carried pending_delete_at; the other ten had no idea the field existed, so the data was being dropped on the floor before the UI ever got a chance. JournalEntryRead also has a parallel JournalEntryReadWithCount that the detail screen reads, which needed it too, or an entry would look safe the moment you opened it.

Countdown rounding (a fix, not just a port)

The countdown now rounds down. The helper was lifted from Home's banner, which rounded up, and that's the wrong direction for this: it's a deadline for undoing something destructive. Telling someone they have "2 days" when 25 hours remain can cost them the window; erring short only makes them act sooner. Below an hour it reads "in under an hour" rather than flooring to "in 0h", which would look like it had already happened.

Home now shares that one implementation instead of keeping its own copy, so the banner and the badges can't drift apart - and the banner picks up the same fix.

Judgement calls

The badge isn't clickable, though web's is a link to the Safety page. These sit inside cards that are already clickable, and a tap target inside a tap target is a coin toss on a phone. Cancelling stays in Settings > Safety, which the Home banner deep-links to.

Relative countdown, not an absolute date. Web shows the finalize date on the badge and puts the countdown on the Safety page. Android already had a relative countdown in the Home banner, so this matches what's there.

Not covered

Watch tokens carry pending_delete_at server-side but have no list UI here to mark. The model field is added for consistency; nothing renders it.

Testing

:app:assemblePlayRelease, :app:assembleOpenRelease, :wear:assembleRelease, :app:testPlayReleaseUnitTest all green. 8 new unit tests cover the countdown boundaries (round-down at 25h and 71h, the sub-hour wording, elapsed deadlines, unparseable input).

Device checklist - needs a system with a grace period configured and something queued for deletion:

• Queue a group delete: the row dims and shows the countdown; the group detail shows it too
• Same for a member, journal entry, poll, reminder, tag, custom field, notification channel
• Cancel it from Settings > Safety: badge and dimming clear on next refresh
• A system with nothing pending looks exactly as before (no stray spacing where badges would be)
• Countdown reads sensibly near the boundaries - just under an hour, just over a day