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

[ClintEastman02]

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

• feat(infra): shared SNS alarm-notification plane (wire bare CloudWatch alarms) — AC5 of #284 #686 — shared SNS alarm-notification plane (wire the alarm here)
• feat(observability): security operations metrics (dwell time and coverage) #485 — security operations metrics (coverage)
• PR chore(security): ratchet silent-success-masking gate + clear 5 Category 3 findings (#756) #788 (the fail-open suppressions)