Repeated usage-limit alerts are held back and remote notification reads are tracked

What

This change affects sessions that run without the interactive screen, such as remote sessions and headless sessions driven by another program. It changes how a repeated usage-limit notice is handled and how queued notifications from the remote side are read.

• repeatsUsageLimitAlert: when the same usage-limit denial comes back with identical quota limits, the turn is marked with this flag and with shouldQuery: false, meaning no new request goes to the model. The flag is passed through the message queue, the session controller, the session loop, a session class and the turn-result class.
• Repeated alerts are handed back like pointer results: a result flagged repeatsUsageLimitAlert is now treated the same as one flagged handbackPointer. Both are added to pendingPointerResults and are no longer flushed early when shouldQuery is false. Before, only handbackPointer results were added there.
• usage_limit_denied_notice is added to a list of names.
• queuedRemoteNotifications gains readsThisTurn, unfinishedReads and nudgeHeldUntil (holding request and cut). Before, it held only pending, drainedIds and nudge.
• Draining queued notifications, which means reading them out, now counts reads in readsThisTurn, removes duplicates from drainedIds and takes a size cap.
• The nudge, a reminder to read waiting notifications, is now one shared sentence telling the model to keep calling until it reports 0 remaining. Before, the text was written inline.
• Agent metadata gains an effort field, and messages from remote sessions may carry remoteToolDenialKind.

Why

In practice, hitting the same usage limit again no longer sends another request to the model, and the repeated notice is delivered with other handed-back results. The new read counters and the nudgeHeldUntil time suggest reminders about waiting notifications can now be held back rather than repeated every turn.