(orchestration): scheduled and pull-request-native task triggers

## Component

API or orchestration

## Describe the feature

Extend the platform beyond ad-hoc task submission with first-class, declarative triggers that create tasks automatically: time-based schedules (cron), source-control events (pull request opened, synchronized, labeled, or CI failure), and optional repo-level automation rules co-located with workflow definitions.

Triggers should resolve to a `workflow_ref`, inherit Blueprint defaults (model, budgets, Cedar policies), and respect existing admission controls (concurrency, idempotency, principal-to-repo authorization when available).

## Use case

I'm always frustrated when valuable background work only runs if someone remembers to run `bgagent submit`. Operations teams want nightly dependency scans, automatic PR follow-up when CI fails, and label-driven workflows (for example, "agent:fix" on an issue) without maintaining external cron jobs or custom webhook scripts. Moving triggers into the platform makes ABCA suitable for always-on, event-driven engineering workflows—not only interactive task submission.

## Proposed solution

1. **Trigger model** — New durable configuration entity (DynamoDB + CDK/API): trigger id, repo(s), event type, filter expression, `workflow_ref`, payload template, enabled flag, last-run metadata.
2. **Schedule path** — EventBridge rules per trigger (or shared scheduler Lambda) that call the existing create-task core with a service principal and idempotency key derived from `(trigger_id, window)`.
3. **GitHub path** — Extend GitHub App / webhook handling for PR and check-run events; map events to triggers with deduplication (avoid one push spawning unbounded tasks).
4. **Config-as-code (optional phase 2)** — Allow `.abca/triggers.yaml` (or workflow metadata) in the repo; Blueprint or deploy step registers triggers in the control plane.
5. **Observability** — Emit `TaskEvents` and CloudWatch metrics for trigger firings, skips, and failures; expose list/status via CLI (`bgagent triggers list`).

## Acceptance criteria

- [ ] Operators can define at least one cron trigger and one PR-event trigger per onboarded repo via CDK or documented API.
- [ ] Fired triggers create tasks that flow through the existing orchestrator state machine and respect concurrency limits.
- [ ] Duplicate firings for the same logical event are suppressed (documented idempotency semantics).
- [ ] User guide documents trigger types, filters, and security implications (service identity, repo scope).
- [ ] Unit/integration tests cover schedule tick, PR webhook mapping, and deduplication.

## Other information

- Related roadmap: **Scheduled triggers**, **Automated re-onboarding**, **EventBridge / SNS integration**.
- Related design: `docs/design/INPUT_GATEWAY.md`, `docs/design/WORKFLOWS.md`, `docs/design/ORCHESTRATOR.md`.
- Existing pieces to reuse: HMAC webhooks, Slack/Linear label triggers, create-task core, durable orchestrator.
- Alternatives considered: document-only "run EventBridge yourself" (high friction); GitHub Actions calling the API ( viable but scatters config and credentials).

## Acknowledgements

- [ ] I may be able to implement this feature
- [ ] This might be a breaking change

Beginne mit dem Lesen von docs/design/INPUT_GATEWAY.md, docs/design/WORKFLOWS.md und docs/design/ORCHESTRATOR.md und verfolge anschließend den bestehenden create-task core, den durable orchestrator und die Verarbeitung von HMAC-Webhooks. Definiere das Trigger-Modell sowie die Zeitplan- und GitHub-Event-Pfade innerhalb der vorgegebenen Einschränkungen für Admission, Autorisierung und Idempotenz. Zum Abschluss gehören die CDK- oder API-Konfiguration, die Integration in den Orchestrator, Deduplizierung, Observability, Dokumentation sowie Tests für Zeitplan, Webhook und Deduplizierung.

Vom Indexierungsmodell aus dem Issue-Text verfasst.