feat(onboarding): automated re-onboarding on default-branch drift

**Context:** ROADMAP.md → Automated re-onboarding

---

## Component

API or orchestration

## Describe the feature

**Event-driven refresh** of blueprint-related artifacts when the default branch changes materially (GitHub webhook); optional EventBridge schedule for periodic drift checks. Distinct from **scheduled triggers** (task creation).

## Use case

Repo layout, dependencies, and conventions drift; stale blueprint context misleads agents. Operators should not manually re-onboard after every structural change.

## Proposed solution

1. Webhook: `push` to default branch → evaluate materiality (path filters, diff size).
2. Refresh: re-index memory hints, regenerate dynamic artifacts (#388), update Blueprint metadata.
3. Optional weekly drift job for quiet repos.
4. Notify operator on significant refresh (Slack/email).
5. Document triggers in `docs/design/REPO_ONBOARDING.md`.

## Other information

- Distinct from #389 (cron task creation).
- Design context: `docs/design/REPO_ONBOARDING.md`.

- [ ] This might be a breaking change

Inizia da docs/design/REPO_ONBOARDING.md e segui i punti di ingresso esistenti dell’API o dell’orchestrazione per l’onboarding, la generazione dinamica degli artefatti (#388) e i trigger delle attività (#389). Definisci come stabilire se un push GitHub sul branch predefinito è rilevante, come vengono gestiti l’aggiornamento e la notifica all’operatore e se la pianificazione opzionale di EventBridge rientra nell’ambito. Il lavoro è completo quando il comportamento dei trigger è documentato ed esiste un design di implementazione concordato.

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