fix: guard against stale /restart redelivery on gateway startup

[dontcallmejames]

Problem

When the .restart_last_processed.json dedup marker is missing (e.g. cleaned up manually or lost due to a filesystem issue), a stale /restart command re-delivered by Telegram's polling can trigger an infinite restart loop: each fresh gateway instance processes the re-delivered /restart and immediately restarts itself again. No Telegram messages are processed during this loop because the polling connection never stays alive long enough.

Hit this in production today — gateway had been restarting every ~2 minutes all day, zero messages processed since April 14.

Fix

Adds a startup-time guard inside _is_stale_restart_redelivery():

• When the dedup marker file is missing AND the gateway process is less than 60 seconds old, treat the /restart as stale and return True
• A legitimate /restart cannot arrive before the gateway has finished its boot sequence plus adapter handshake; anything arriving this early is a re-delivery from the previous gateway cycle

Changes

1. Added self._startup_time: float = time.time() in GatewayRunner.__init__
2. Added early-return guard: when marker missing + uptime < 60s → return True

The existing marker-file dedup mechanism is the right primary defense; this is belt-and-suspenders for when that file goes missing.

[krkln]

We hit this exact bug in production (June 2026 — gateway restart loop, zero messages processed). Applied the same fix with a 10s cooldown instead of 60s — works. Our PR #43472 was marked as duplicate of this one. Thanks for the fix, hope it gets merged soon!

[teknium1]

Merged via #56107 (commit cdd5539 on main). Thanks for the diagnosis and the original patch — you correctly identified the root cause (missing dedup marker → redelivered /restart bypasses the update_id check → infinite restart loop) and hitting it in production made the failure mode concrete.

The guard was reworked in the salvage: instead of a bare "uptime < 60s → stale" window, it now suppresses the /restart only when it can independently confirm the process just came out of a restart cycle (_booted_from_restart, captured at startup from .restart_notify.json before it's unlinked) and is still within the 60s post-boot window, consumed one-shot. This closes the loop without the side effect the bare-uptime version had — the marker is missing on every fresh install / first-ever restart, so a blanket timer would silently swallow a legitimate first /restart a user sends right after boot.

Your name is in the merge commit and PR body. Appreciate the fix.