/compact resurrects /loop skill context, causing stale cron jobs to keep executing after user stopped the loop

Summary

After /compact runs in a conversation that previously used /loop, the skill guidance is replayed into the new compacted context ("⎿ Skills restored (loop)"), and the conversation keeps honoring the loop contract — even though the user explicitly stopped it, and even though CronList in the compacted session returns no jobs.

Repro

1. In a conversation, run /loop 5m <prompt> — this creates a recurring cron
2. Later in the same conversation, ask Claude to stop the loop
3. Run /compact
4. After compaction, the next cron fire arrives as a user message
5. Claude sees ### Skill: loop in the top-of-context system-reminder, treats itself as still under the loop contract, and re-executes the prompt
6. CronList in the compacted session returns "No scheduled jobs", so Claude cannot CronDelete the job that is actually still firing

What I believe is happening

• CronCreate jobs are scoped to the session that created them
• When a cron fires, a new conversation is spawned with the loop prompt injected as a user message
• /compact preserves "skills invoked in this session" and re-injects them as guidance, so the compacted session still believes it's under an active loop contract
• But compaction also gives the session a fresh cron scope — CronList / CronDelete only see jobs created in the compacted session, not the parent
• Net effect: the user cannot turn off a loop that was scheduled pre-compaction from inside the compacted conversation. The only escape is to wait 7 days for auto-expiry, or to claude -r <original-session-id> into every session that created a loop and CronDelete from there

Impact

• /loop + /compact is a trap: once a user compacts a session that had a loop, they have no in-band way to stop the loop
• The user can say "stop the loop" repeatedly and Claude will acknowledge — but nothing is actually being canceled, because the cron is owned by a session Claude can no longer see
• In my case, 9 separate /loop invocations across different sessions from several days ago are still firing, each spawning fresh conversations that appear to obey the same "5m check status" contract

Suggested fixes

1. /compact should either (a) surface outstanding crons from the pre-compaction session in the post-compaction CronList, or (b) strip loop-skill guidance from the replayed skill list if the underlying cron is no longer reachable
2. CronList / CronDelete should operate on a per-project or per-user scope, not per-session — so the user always has a way to see and cancel their own loops regardless of which session originated them
3. "Skills restored" replay should probably not include /loop, since the loop's contract is tied to a specific cron job, and that binding breaks on compaction