feat(observability): emit a CloudWatch metric when webhook guardrail screening fails (fail-open silently degrades enrichment)

Non-blocking follow-up from the PR #788 review (silent-failure-hunter finding).

## Problem

The three webhook screening paths — `jira-webhook-processor.ts` `screenCommentsOrDrop`, and `linear-webhook-processor.ts` `screenProjectDocsOrDrop` / `screenCommentsOrDrop` — fail **open** on a Bedrock Guardrail error: they `logger.warn(...)` and drop the third-party content so the task proceeds. That posture is correct (see the ADR proposed in #793), but the only signal is a log line. A **sustained** Bedrock Guardrail outage would silently degrade comment/doc enrichment fleet-wide, discoverable only via log search — there is no metric and nothing to alarm on.

## Proposed fix

Emit a CloudWatch metric (e.g. `WebhookScreeningFailed` with a `source` dimension — `jira-comments` / `linear-docs` / `linear-comments`) on each fail-open path, so the degradation is graphable and alarmable. Wire it into the shared alarm plane rather than a bespoke alarm.

## Related

- #686 — shared SNS alarm-notification plane (wire the alarm here)
- #485 — security operations metrics (coverage)
- PR #788 (the fail-open suppressions)

Inizia leggendo i tre percorsi di screening indicati in jira-webhook-processor.ts e linear-webhook-processor.ts, quindi esamina il piano condiviso di notifica degli allarmi SNS descritto in #686. Aggiungi una metrica CloudWatch per ogni origine fail-open e collegala a quel piano di allarmi condiviso, in modo che tutti e tre i percorsi webhook producano il segnale previsto.

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