mastodon polling fix

The polling loop was updating last_notification_id on every iteration,
leaving it set to the oldest (smallest) ID in the batch after the loop
completed. On the next poll, since_id was set to that oldest ID, causing
Mastodon to return all previously seen notifications again.

Re-delivered notifications caused the bot to respond to the same user
mention repeatedly. Combined with api_post_status chaining each response
chunk as a reply to the previous chunk, this produced long self-reply
threads that appeared to be the bot conversing with itself.

Fix: capture the first (newest) notification ID before processing the
batch, so since_id always advances correctly on each poll cycle.

Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com>

crates/openfang-channels/src/mastodon.rs

@@ -456,10 +456,18 @@ impl ChannelAdapter for MastodonAdapter {
                 let notifications: Vec<serde_json::Value> =
                     poll_resp.json().await.unwrap_or_default();
 
-                for notif in &notifications {
-                    if let Some(nid) = notif["id"].as_str() {
+                // Mastodon returns notifications newest-first. Record the first
+                // (highest) ID before processing so we never re-fetch these on
+                // the next poll. Updating inside the loop would leave us with
+                // the oldest ID, causing every previously seen notification to
+                // be re-delivered and re-processed.
+                if let Some(newest) = notifications.first() {
+                    if let Some(nid) = newest["id"].as_str() {
                         last_notification_id = Some(nid.to_string());
                     }
+                }
+
+                for notif in &notifications {
                     if let Some(msg) = parse_mastodon_notification(notif, &own_account_id) {
                         if tx.send(msg).await.is_err() {
                             return;