[Feature] [P2/P3/P4]: Cron Task Safety Defaults and Notification Granularity

## QwenPaw Version
- 0.2.1

## Description
### Tool Safety Check: Default OFF [P2]

**Bug Report**

**Current behavior:** "Tool Execution Safety Check" defaults to **OFF** for Cron tasks.

**The problem in practice:**
I get the intent — you don't want a popup blocking your scheduled run. But here's the thing: **agents go off-script, especially smaller models.** I've seen Cron tasks spiral because the model "thought" it needed something, or because it hit a failure and decided to "try again," resulting in:
- Installing a cascade of unrelated dependencies
- Executing bash commands that have nothing to do with the actual task
- Running file operations on the wrong paths

Defaulting safety checks to OFF for unattended automation is a footgun.

**What should happen:**
The Cron task creation flow (the skill/prompt that guides users through setup) should **explicitly warn** about this risk and surface the choice instead of silently applying a default. Something like:

> "This task will run while you're away. Disabling safety checks means the agent can execute any tool without approval. If the model hallucinates or retries aggressively, it could install unwanted packages or execute unintended commands. Are you sure?"

My personal preference: **ON** for anything I didn't personally verify. The setup cron should ask, not assume.

---

### 2. No Way to Kill a Running Cron Task from Chat [P2/P3]

**Feature Request**

**Current behavior:** `/stop` only works for the current chat session. It does **nothing** to a Cron task that's currently executing in the background.

**The problem in practice:**
You notice your Cron agent is going off the rails — stuck in a loop, hammering an API, or running commands you didn't expect. You type `/stop` in chat. Nothing happens because the Cron runs in an isolated session. Your only option is to manually restart the entire application. By the time you act, the agent may have already modified files or progressed the process in an unintended way.

**What I'd like:** A command like `/stop-cron` that can terminate an in-flight Cron execution from the chat interface. Even a simple "emergency brake" that halts all pending tool calls for that scheduled run would prevent further damage.

---

### 3. Silent Delivery Lacks a "Result-Only" Option [P3]
- He may have fixed it, but I'm not so sure becauseThe description of the page is not very clear, May be related to the following reports and PR:
- #6177
- #6182

**Current behavior:** Silent Delivery is a binary toggle. Either everything (reasoning traces + tool outputs) floods your QQ channel, or nothing goes to the channel and you must check the web inbox.

**The problem in practice:**
When I'm **debugging** a new Cron job, I want the full trace in QQ — helps me see where it went wrong. But once the task is **stable and running in production**, my phone shouldn't buzz every ~10 seconds.

---
### 4. Ask, Don't Assume [P4]

All three of these — Tool Safety Check, Silent Delivery mode, and Session Sharing — are **highly preference-driven**. There's no universal right answer:

- Some users want full transparency; others want zero noise.
- Some trust their agents completely; others (like me) have been burned by runaway tool calls.
- Some want session continuity across runs; others want clean isolation.

**The real request:** When a user creates a Cron task, QwenPaw should **actively ask** about these settings in the setup skill/prompt instead of silently applying defaults. A 30-second guided setup beats hours of cleanup from a misconfigured unattended agent.

---

## Component(s) Affected

- [x] Core / Backend (app, agents, config, providers, utils, local_models)
- [x] Console (frontend web UI) - `The related functions should be described in more detail`
- [ ] Channels (DingTalk, Feishu, QQ, Discord, iMessage, etc.)
- [x] Skills
- [ ] CLI
- [ ] Documentation (website)
- [ ] Tests
- [ ] CI/CD
- [ ] Scripts / Deploy

## Environment
- **QwenPaw version:** 0.2.1
- **OS:** MacOS 26.5.2
- **Install method:** Docker