[BUG] Assistant text immediately before a turn-ending tool call (e.g. ScheduleWakeup) never renders — breaks the documented self-pacing loop pattern

Environment

• Claude Code v2.1.202 (autoUpdatesChannel: latest)
• Windows 11 Pro (10.0.26200), Windows Terminal
• "tui": "fullscreen" (symptom matches reports on default TUI too — see referenced issue)

Summary

When the assistant writes text and then ends the turn with a tool call — the exact shape the /loop dynamic-mode (self-pacing) skill instructs: "Briefly confirm… write this as text before calling ScheduleWakeup — the turn ends as soon as that tool returns" — the text written before that final tool call never renders for the user. The user sees nothing from the turn. Observed consistently across many loop ticks on multiple days.

This appears to be the same root cause as #24691 ("Streaming text disappears entirely when followed by tool calls in same response"), which was closed by the inactivity bot ("not planned") and is now locked, with its bot comment directing: "please file a new issue and reference this one." This is that issue: the bug is still fully present on v2.1.202.

Repro

1. Ask for a self-paced recurring task (/loop <prompt> with no interval).
2. The model does a work unit, writes a status summary, then calls ScheduleWakeup as its last action (exactly per the skill's instructions).
3. Observe: the summary text is not displayed — the turn appears to produce no output. Repeats on every tick.

Expected

Text streamed before a turn-ending tool call renders and persists in the transcript.

Impact

• Self-pacing loops are effectively mute: every per-tick update is invisible, so users interrupt working loops to ask "what's happening?", or miss decisions the loop surfaced.
• The obvious workaround is also unavailable: PushNotification fails from scheduled/wakeup contexts (#49756, "Remote Control inactive"), so there is no supported channel for a loop tick to reach the user.
• Net effect: the shipped scheduled-task/loop features contradict their own documented usage pattern.

References

• #24691 (same symptom; closed for inactivity, locked — filing anew per its bot's instruction)
• #49756 (PushNotification unavailable from scheduled tasks — removes the workaround)