fix(notifications): keep unchanged toast cards mounted, carry the hover hold across a rebuild

[vibechoom]

apply_emission rebuilt every live toast card on every emission of the
combined toast signal. Destroying a card fires its connect_unmap, which
attach_hover_pause (#569) uses to release the service-side hover hold — right
in isolation, since GTK doesn't guarantee a leave on unmap. The replacement
came up with a fresh holds_enter = false, and GTK4 only retargets pointer
focus while processing a crossing or motion event, so a stationary pointer
produced no enter and the pause was never re-established.

Net effect: park the pointer on a toast to read it, let any other notification
arrive or expire, and the countdown silently resumed — the toast dismissed
mid-read. Exactly what #567 was filed to prevent.

Option 1, plus a hold transfer for the residual case

Option 1 (don't rebuild unchanged cards) is what shipped here — the
replaces_id semantics check out for it:

• Notify builds a whole new Notification and does *existing = notification
  on a replaces_id re-post, so "unchanged" is a content question, not a
  mutation-tracking one.
• Nothing rendered on a card changes without the content changing.
  created_at is re-stamped by every re-post, and timeout can change, but
  neither reaches the widget tree — so whole-struct equality would have been
  the wrong predicate even if Notification derived PartialEq (it doesn't;
  NotificationImage::Raw carries a pixel buffer).

card_content_eq therefore compares exactly the fields build_card reads, and
its doc comment says to keep the two in sync. The CardEntry that replaces the
bare gtk::Widget in card_map keeps the notification snapshot to compare
against.

That kills the reported failure (an unrelated notification arriving or
expiring) outright. It leaves one narrower case: a genuine replaces_id update
to the toast under the pointer still has to swap the widget, and would still
drop the hold. So replace_card also carries the hold (the issue's option
2, now scoped to the cards that actually need rebuilding): when the outgoing
card holds, a second hold is taken before it is unmapped, so its teardown
only drops the service-side count 1 → 2 → 1. It never reaches zero, nothing
re-arms mid-hover, the recorded remainder is never recomputed or floored, and
the fresh card inherits the hold via its seeded holds_hover, whose eventual
leave/unmap balances it exactly once.

The invariant the connect_unmap teardown protects is intact: it still runs on
every card, and it is still what balances the count when a card goes away while
genuinely hovered. Nothing double-decrements — and TimerState::resume already
clamps a leave with no matching enter to a no-op.

Two smaller consequences of not rebuilding, both deliberate:

• replace_card keeps the card's place (prev_sibling +
  insert_child_after) instead of re-appending. With everything rebuilt each
  pass, stack order was arbitrary anyway (HashMap iteration); now that it's
  stable, an updated toast jumping to the bottom would be newly visible.
• The overflow card is left rebuilding unconditionally. It holds no hover
  state, and the remove-then-append is what keeps it pinned below any card the
  main loop appended this pass.

Residual, documented on replace_card

If a replacement card is small enough that the pointer no longer lies over it,
no leave ever comes and the inherited hold lasts until the card unmaps — the
toast then waits for a dismiss instead of expiring. Bounded (the teardown still
balances the count) and strictly the safer of the two failures. Querying the
pointer (the issue's option 3) wouldn't fix this either: the fresh card has no
allocation until the next layout pass.

Tests

Hermetic, both buckets:

• trollshell::overlays::notifications — card_content_eq and its two
  helpers: identical notifications keep the card; one case per rendered field
  forcing a rebuild; created_at/timeout churn not forcing one; action
  label/order/length; image variant + payload equality (same dimensions,
  different pixels must rebuild).
• hytte-services::notifications —
  hold_transfer_across_a_card_rebuild_never_unpauses pins the 1 → 2 → 1
  transfer sequence on the pure TimerState: stays paused, remainder
  untouched, and only the successor's leave re-arms.

Not covered, and not coverable in CI: the GTK half — that a stationary
pointer produces no enter on a replacement widget — needs a real compositor
and a real pointer. That's what the live-verify below is for.

Live-verify

Needs a running Niri session; I can't run one.

1. The decisive test. notify-send "A" "park the pointer here" -t 5000,
   put the pointer on the toast and do not move it. After ~2s, from another
   terminal: notify-send "B" "unrelated". A must still be there — it must
   not dismiss while the pointer sits still. Move the pointer off A; it should
   then expire within roughly the time it had left (floored at 1s). Before this
   change, A vanished ~4s after B arrived.
2. Repeat-fire. With the pointer parked on A, fire three more notifications
   a second apart. A stays.
3. replaces_id under the pointer. id=$(notify-send -p "P" "0%" -t 5000),
   park the pointer, then notify-send -r "$id" "P" "50%" -t 5000. The card
   updates in place (same position in the stack, not re-appended to the bottom)
   and still does not expire under the stationary pointer.
4. No stranded pause. Hover a toast, then dismiss it with its ✕ (or let a
   5th non-critical toast push it out of the visible head). Nothing should be
   left paused: subsequent toasts must expire on their own normally.
5. Ordering / overflow. With >4 non-critical toasts live, the "+N more"
   card stays at the bottom of the stack as toasts come and go.

Closes #593

[vibechoom]

Review (maintainer pass) — no blocking findings

I asked for option 1 if the evidence supported it, and told you not to force it. You read replaces_id first, found option 1 holds, and found that the naive version of it would have been wrong. That's the right sequence.

The correction to my preference

Whole-struct equality would have rebuilt on every re-post, because Notify re-stamps created_at (and timeout can change) while neither reaches the widget tree. card_content_eq comparing exactly the fields build_card reads — documented as needing to stay in sync with it — is the correct predicate, and avoids adding PartialEq derives to service data shapes just to serve a widget concern.

Doing both options, correctly scoped

Option 1 alone would have fixed the reported symptom (an unrelated notification arriving) and left a genuine replaces_id update under a stationary pointer exhibiting the identical bug. Adding the hold transfer for cards that must genuinely be rebuilt closes that too.

The ordering is what makes it work, and it's right: pause_expiry is taken before vbox.remove() fires the outgoing card's unmap. I verified the service-side semantics that relies on — TimerState::pause only aborts on the first hold, and resume only re-arms when the count reaches 0 (crates/hytte-services/src/notifications.rs:594-622). So 1 → 2 → 1 leaves the timer aborted with remaining untouched: no recomputation, no floor reapplied, no double-decrement. And the connect_unmap teardown still runs on every card, so the leak-prevention invariant the original comment protects survives intact.

Adding a service-side test for the transfer rather than only overlay tests was the right instinct — the invariant lives on that side.

The documented residual — correctly reasoned

If a replacement card is small enough that the pointer no longer lies over it, no leave arrives and the inherited hold persists until unmap, so the toast waits for a dismiss instead of expiring. Three things make this the right call rather than a gap:

1. It's bounded — teardown still balances the count.
2. It's the safer of the two failure modes. A toast that lingers is a nuisance; one that vanishes mid-read is the bug we're fixing.
3. Option 3 genuinely can't fix it — a fresh card has no allocation until the next layout pass, so querying the pointer would just read a stale rectangle. Saying so is more useful than silently picking option 3 and shipping a subtler version of the same bug.

Also noted

Preserving stack position via prev_sibling + insert_child_after is a real improvement — ordering was previously HashMap-arbitrary on rebuild. And fixing your own type_complexity clippy failure with a type Mutation alias rather than an #[allow] is the right reflex.

Live-verify remains the decisive test and can't run in CI: park the pointer on toast A, fire B from another app, and A must not dismiss while the pointer sits still.

[vibechoom]

CI green ✅

flake-check SUCCESS (27m49s — the fastest run yet). Mergeable, reviewed above, no blocking findings.

@annikahannig this is the one that restores what #567 was for. The decisive check, which CI structurally cannot do: park the pointer on a toast to read it, have another app fire a second notification, and the first must not dismiss while your pointer sits still. Before this, any other notification arriving or expiring silently resumed the countdown on every live toast.