feat(engine): extend Mission types with webhook/event triggers + evolving strategy

Mission types updated to support external activation sources:

MissionCadence expanded:
- Cron { expression, timezone } — timezone-aware scheduling
- OnEvent { event_pattern } — channel message pattern matching
- OnSystemEvent { source, event_type } — structured events from tools
- Webhook { path, secret } — external HTTP triggers (GitHub, email, etc.)
- Manual — explicit triggering only

The engine defines trigger TYPES. The bridge implements infrastructure
(cron ticker, webhook endpoints, event matchers). GitHub issues, PRs,
email, Slack events all use the generic Webhook cadence — no
special-casing in the engine. Webhook payload injected as
state["trigger_payload"] in the thread's Python context.

Mission struct extended:
- current_focus: what the next thread should work on (evolving)
- approach_history: what we've tried (for adaptation)
- max_threads_per_day / threads_today: daily budget
- last_trigger_payload: webhook/event data for thread context

Plan updated with trigger type table and webhook integration design.

Co-Authored-By: Claude Opus 4.6 (1M context) <[email protected]>

docs/plans/2026-03-24-missions.md

@@ -44,6 +44,29 @@ pub struct Mission {
 
 Already defined in `crates/ironclaw_engine/src/types/mission.rs`.
 
+## Trigger Types
+
+The engine defines trigger *types*. The bridge implements the actual infrastructure:
+
+| Trigger | Engine type | Bridge implementation |
+|---|---|---|
+| Cron schedule | `MissionCadence::Cron { expression, timezone }` | Tokio interval task, cron parser |
+| Channel message | `MissionCadence::OnEvent { event_pattern }` | Regex match in `handle_message` before routing |
+| System event | `MissionCadence::OnSystemEvent { source, event_type }` | Match events from `event_emit` tool |
+| Webhook | `MissionCadence::Webhook { path, secret }` | Register HTTP endpoint on webhook server |
+| Manual | `MissionCadence::Manual` | `mission_fire` tool or API call |
+
+**Webhook-based integrations** (GitHub, email, etc.) use the generic `Webhook` cadence. The webhook payload is stored as `mission.last_trigger_payload` and injected into the thread's context:
+
+```python
+# Inside the mission's thread, the trigger payload is accessible:
+payload = state["trigger_payload"]
+# For a GitHub webhook: payload["action"], payload["issue"]["title"], etc.
+# For email: payload["from"], payload["subject"], payload["body"]
+```
+
+This means GitHub issues, PRs, email, Slack events, etc. all work through the same webhook mechanism — no special-casing in the engine.
+
 ## Architecture
 
 ```