[FEATURE] CronCreate: add skill_context parameter to apply skill's allowed-tools at fire time

Preflight Checklist

• [x] I have searched existing requests and this feature hasn't been requested yet
• [x] This is a single feature request (not multiple features)

Problem Statement

When a skill schedules a recurring job via CronCreate, the cron fires without any skill context — the harness has no knowledge that the job was created by a skill. This means the skill's allowed-tools frontmatter is ignored at fire time.

Any tool the cron needs must be duplicated into settings.json and settings.local.json manually. For a skill that uses 20+ tools and Bash patterns, this creates three places to maintain the same list: the skill frontmatter, settings.json, and settings.local.json. Adding or changing a permission requires updating all three.

Proposed Solution

Add an optional skill_context parameter to CronCreate:

CronCreate(
cron: "/5 *",
prompt: "...",
skill_context: "alert-watch" // ← new
)

At fire time, the harness would load the named skill's allowed-tools and apply them for the duration of that cron invocation — exactly as it does during an interactive skill session.

This makes allowed-tools in the skill frontmatter the single source of truth, with no permission duplication in settings.json.

Alternative Solutions

Manually copy all allowed-tools entries into settings.json + settings.local.json, and keep them in sync on every skill update. This is error-prone and breaks portability across machines/users.

Priority

High - Significant impact on productivity

Feature Category

Configuration and settings

Use Case Example

1. I have a skill alert-watch that monitors a Slack alerts channel every 5 minutes
2. The skill declares 20+ allowed-tools in its frontmatter (MCP tools, Bash patterns, etc.)
3. The skill calls CronCreate to schedule itself
4. The cron fires but ignores the skill's allowed-tools — every tool triggers a permission prompt or fails silently
5. With skill_context: "alert-watch", the cron would inherit the skill's permissions and run unattended as intended

Additional Context

Related issue: #24798 — overlapping concern around permissions for unattended autonomous operation