Scheduled task never records lastRunAt despite a normal recurring cron schedule

Observed: Across three separate checks spanning 2026-08-26 07:50 UTC through 19:03 UTC (two independent sessions), a scheduled task (webapp-core-watchdog, cadence */15 * * * *) has never shown a populated lastRunAt field via mcp__scheduled-tasks__list_scheduled_tasks, while its nextRunAt field advances normally on schedule each time it's queried. In the same list, 12 other tasks — including several on daily/15-minute-class cadences — show fresh, populated lastRunAt timestamps from executions earlier the same day.

Ruled out:

• Scheduler-wide outage: other tasks fire normally, including a visible batch-catchup of previously-overdue tasks in the same session.
• Premature checking: verified via [DateTime]::UtcNow that checks ran after the task's own scheduled fire time.
• One-time vs. recurring entry type: the task is a standard cron entry (*/15 * * * *), not a leftover one-time fireAt arm.

Tried and did not fix it:

• Toggling enabled: false then true via update_scheduled_task — complete no-op, lastRunAt/nextRunAt unchanged before and after.
• Forcing a one-time fireAt re-arm a few minutes in the future — did not fire even after its own scheduled time passed, while other previously-stalled tasks caught up and fired successfully in that same window.

Not yet tried: deleting and recreating the task under a fresh task ID (would lose task history/identity, so flagging rather than doing this unilaterally).

This makes it impossible to trust lastRunAt as a liveness signal for at least this specific task, and the root cause (why this one task specifically never gets a lastRunAt write while others on the same subsystem do) is unclear from the outside.