fix: track newest notification ID in Mastodon polling fallback

[Fail-Safe]

Summary

• Fixes since_id tracking in the Mastodon REST polling fallback so previously seen notifications are never re-delivered
• Moves the last_notification_id update out of the processing loop and captures the first (newest) notification ID before iterating

Problem

Mastodon returns notifications in reverse chronological order (newest first). 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, so the API returned all notifications newer than it — including every notification already processed in the previous batch. This caused the bot to respond to the same user mention repeatedly on every poll cycle.

Combined with api_post_status chaining each response chunk as a reply to the previous chunk, repeated responses accumulated into long self-reply threads that appeared to be the bot conversing with itself.

Test plan

• Verify cargo test -p openfang-channels passes cleanly
• Confirm that after the bot responds to a Mastodon mention, no duplicate responses are posted on subsequent poll cycles
• Verify behaviour is correct when a poll returns multiple notifications (only new ones processed next cycle)

🤖 Generated with Claude Code