fix(gateway): recover resume_pending sessions instead of sending a blank turn

[hashbender]

Summary

After a gateway restart, an auto-resumed thread now always gets its recovery system note instead of occasionally receiving a genuinely blank user turn (which made the model reply with confused "that message came through blank" noise).

Root cause: _schedule_resume_pending_sessions dispatches an empty-text turn expecting the injector to fill it with a recovery note, but the scheduler judges freshness off last_resume_marked_at (interrupt time) while the injector gates _is_resume_pending on the transcript clock (_last_transcript_timestamp). For a thread quiet >1h before the crash, those disagree → _is_resume_pending goes False → the note is never injected → the model gets a blank user turn.

Changes

• gateway/run.py: (1) dual freshness signal — _is_resume_pending now fires when the transcript clock or last_resume_marked_at is within the window, so the scheduler's decision and the per-turn injection agree. (2) empty-turn safety net — if message is still blank AND the session is resume_pending, backfill the recovery note; scoped to resume_pending so a legitimately empty user turn (uncaptioned image) on a normal session is untouched. The safety-net note reuses the canonical reason-aware recovery wording from the _is_resume_pending branch (follow-up on the salvage).
• scripts/release.py: AUTHOR_MAP entry for the salvaged commit.

Validation

	Before	After
Interrupted-just-now, transcript row 1h+ old	_is_resume_pending=False → blank turn	dual signal → note injected
Blank turn on resume_pending (branch missed)	reaches model empty	backfilled recovery note
Blank turn on ordinary session	untouched	untouched
tests/gateway/test_restart_resume_pending.py	—	78 passed (3 new, confirmed RED pre-fix)

E2E-verified against the real _is_fresh_gateway_interruption / _last_transcript_timestamp helpers: the exact stale-transcript bug case flips from False (old single-signal) to True (dual signal).

Salvaged from NousResearch#46997 by @abchiaravalle (first-time contributor); authorship preserved via rebase-merge.

Infographic

Nous Research

---

Mirror-of: NousResearch#56262
NousResearch#56262