fix: answer a text that arrived while the Mac was asleep

Closes #16.

The cutoff stays exactly as it was. A Mac waking up must not replay a day of texts, because a replayed day could do real work nobody wants now. What was wrong was the silence.

Over a satellite link the send itself may have taken minutes, and getting nothing back is both the worst available answer and indistinguishable from Uplink being broken.

What you get now

One text:

That arrived 2 hours ago, while this Mac was asleep, so I did not run it.
Send it again to run it now.

Eight:

8 texts arrived while this Mac was asleep, the most recent 2 hours ago.
I ran none of them. Send one again to run it now.

The four rules it follows

• It never runs a stale task. That is what the cutoff is for. Sending it again runs it, and the reply says so, which is the whole recovery path.
• One reply per chat per wake, whatever the backlog. A Mac that slept through eight texts owes an explanation, not eight of them, and the inbound link is thin.
• Control words are left out. status and stop are answered live or not at all, and reporting that a midnight status went unanswered is noise.
• Nothing older than a day is mentioned. Waking a Mac that slept a week should not text about Tuesday, and by then whoever sent it has long since given up.

Verification

Five new tests, one per rule plus a mixed wake proving the fresh text in the same tick still runs normally and only the old one is explained.

144 unit tests pass, lint and typecheck clean.

🤖 Generated with Claude Code