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)

Start by reading the three named screening paths in jira-webhook-processor.ts and linear-webhook-processor.ts, then inspect the shared SNS alarm-notification plane described in #686. Add a CloudWatch metric for each fail-open source and wire it into that shared alarm plane, with all three webhook paths producing the expected signal.

Written by the indexing model from the issue text.