(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

Inizia leggendo docs/design/INPUT_GATEWAY.md, docs/design/WORKFLOWS.md e docs/design/ORCHESTRATOR.md, quindi traccia il create-task core esistente, il durable orchestrator e la gestione dei webhook HMAC. Definisci il modello dei trigger e i percorsi di schedule e degli eventi GitHub nel rispetto dei vincoli indicati di ammissione, autorizzazione e idempotenza. Il lavoro completato include la configurazione CDK o API, l’integrazione con l’orchestrator, la deduplicazione, l’osservabilità, la documentazione e i test per schedule, webhook e deduplicazione.

Scritto dal modello di indicizzazione a partire dal testo della issue.