feat(security): principal-to-repo authorization

**Context:** ROADMAP.md → Credentials and authorization → Principal-to-repo authorization
**Related:** #249, #389 (mentions principal-to-repo when available)

---

## Component

API or orchestration

## Describe the feature

Map Cognito identities (and future auth principals) to allowed repository sets so users can only submit tasks, webhooks, and channel triggers against repos they are authorized to access. Enforce at task creation and admission time (fail-closed).

## Use case

Multi-user deployments cannot rely on shared PATs or implicit trust. Operators need tenant isolation: Alice may trigger work on `org/frontend` but not `org/payments-core`. Without this, any authenticated user with API access can target any onboarded repo.

## Proposed solution

1. Add a `PrincipalRepoAccess` (or equivalent) store: principal identity → allowed `repo` patterns or explicit repo IDs.
2. Validate in `createTaskCore` / webhook processors / channel adapters before hydration.
3. Admin/operator APIs or CDK Blueprint hooks to manage mappings per team.
4. Return `403 REPO_NOT_AUTHORIZED` with clear CLI messaging.
5. Document operator setup in user/developer guides.

## Other information

- Complements per-session IAM scoping (#209) and identity propagation (#249).
- Scheduled triggers (#389) should inherit the same authorization model.
- Design context: `docs/design/SECURITY.md`, `docs/design/API_CONTRACT.md`.

- [ ] This might be a breaking change

Start by reading docs/design/SECURITY.md and docs/design/API_CONTRACT.md, then trace createTaskCore, webhook processors, and channel adapters. Define how principal-to-repository mappings are managed and enforced before hydration, including scheduled triggers. Done means unauthorized access fails closed with 403 REPO_NOT_AUTHORIZED, CLI messaging is clear, and operator setup is documented.

Written by the indexing model from the issue text.