Registering immediately sends a summary #2

Fixed on the fix/no-registration-summary branch. The unread-count baseline alone could not keep the backlog from firing once: getUnreadCount answers a higher number than listNotifications shows (the appview counts activity it never lists - muted accounts, review queues), so the first hinted check saw unread > 0, listed, and summarized pre-registration activity into one burst. Grant time now claims every listed URI in the dedupe ledger, so the first poll cycle finds the backlog already delivered and sends nothing. Only the first page is claimed - exactly the page the first delivery reads, so the two cannot disagree about what is old. A listing failure degrades to the bare-count baseline as before, and a tier change re-seeds on top of preserved counters rather than wiping them. Deployed live on courier.7778777.online.

I'm not 100% sure this is right but we'll see

Follow-up after auditing the actual grant and poll path: the previous fix was incomplete. It only claimed the first listing page, so an old event indexed later could still be announced, and if that initial listing failed there was no durable registration cutoff at all. Its test exercised the ledger helper, not registration followed by delivery.

59c0445 on main now stores the first registration time in the existing notification watermark and compares each record createdAt against it. Old records cannot become new pushes after a failed baseline listing or delayed indexing. Reauthorization preserves the original boundary, and newly created events still deliver.

The new regressions drive the real token exchange and first poll, including a one-shot listing failure and an old record indexed after registration. They also verify that reauthorization does not suppress a new event. Full local tests, clippy and the black-box conformance suite pass (100% core and bonus on rerun).