(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

Start by reading docs/design/INPUT_GATEWAY.md, docs/design/WORKFLOWS.md, and docs/design/ORCHESTRATOR.md, then trace the existing create-task core, durable orchestrator, and HMAC webhook handling. Define the trigger model and schedule and GitHub event paths within the stated admission, authorization, and idempotency constraints. Done includes CDK or API configuration, orchestrator integration, deduplication, observability, documentation, and schedule, webhook, and deduplication tests.

Written by the indexing model from the issue text.