[BUG] Scheduled tasks: updateScheduledTask strips unknown SKILL.md frontmatter keys, from 3 different triggers (MCP tool, permission auto-approve, GUI edit)

App version: 1.52386.6 (Desktop, macOS)

Observed behavior: the internal CCDScheduledTasksApi.updateScheduledTask call — logged as [ScheduledTasks] Updated task file — regenerates a scheduled task's SKILL.md frontmatter from a known-fields schema (name/description/etc.) and silently drops any frontmatter key it doesn't recognize. We use a custom frontmatter key for our own tracking purposes and lost it repeatedly with no error, no warning, and no way to tell it had happened short of diffing the file.

This call fires from at least three distinct triggers, confirmed via ~/Library/Logs/Claude/main.log:

1. The update_scheduled_task MCP tool, called explicitly by a session.
2. An in-run auto-persist of a newly-approved tool permission — a run needs a permission not yet in the task's stored allowlist, it gets approved, and the app persists that approval by rewriting the whole SKILL.md file as a side effect. Log excerpt:

``
[CCDScheduledTasks] Added 1 approved permission rule(s) to task "<task>"
[CCDScheduledTasksApi] updateScheduledTask: scheduledTaskId=<task>
[ScheduledTasks] Updated task file: ~/.claude/scheduled-tasks/<task>/SKILL.md
``

1. What appears to be a GUI edit through the Scheduled Tasks panel — same API call, preceded by a LocalSessions.checkTrust for the task's associated project directory rather than any tool_use event.

Only trigger #1 is visible to a Claude Code session (as an MCP tool_use event) — triggers #2 and #3 happen with no corresponding session event at all, so there is no way for a hook, or anything else running inside a session, to detect or react to the loss.

Separately, deleting a scheduled task (updateScheduledTaskStatus with status=deleted) does not remove its ~/.claude/scheduled-tasks/<id>/ directory unless removeFiles is explicitly passed — an easy thing to miss, since the UI's delete action doesn't surface that distinction, leaving an orphaned directory with no corresponding task.

Impact: any workflow that relies on a custom frontmatter key surviving in a task's SKILL.md is unreliable, because the key can vanish on an ordinary run (trigger #2) with zero visibility. We worked around it by moving our own tracking data into a sidecar file next to SKILL.md instead, but that's only possible for data we control entirely outside the app's schema.

Ask: updateScheduledTask's SKILL.md rewrite should preserve any frontmatter key it doesn't recognize, merging into its own known fields rather than replacing the whole frontmatter block. Failing that, at minimum the two non-MCP triggers (#2 and #3) should be visible somewhere a script or hook could detect them (a log line alone isn't enough for anything running outside the desktop app itself).