Extend notification subscription schema, metrics rules directory, and CI validation

## Goal

Extend existing subscription YAML so recipient entries can carry per-notification preferences, add a directory for metrics rules, and validate everything in CI. **No change to sending behavior in this issue.**

Part of notification subscriptions and delivery (YAML / PR onboarding).

## Recipient entries

In `backend/data/notifications/subscriptions/`, an entry under `default_recipients` may be either:

- a **plain string** (unchanged: Cc on regression reports and checkout summary for this tree/hardware), or
- a **mapping** with `email` plus optional blocks such as `new_issues`.

```yaml
broonie-sound:
url: https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
default_recipients:
- someone-else@kernel.org
- email: broonie@kernel.org
new_issues:
issue_types: [boot]
reports:
- for-linus:
branch: for-linus
```

Hardware files use the same pattern on `default_recipients`.

`issue_types`: `build` (build incident), `boot` (boot test path), `test` (other test). Document that full regression reports prefer **build** when both build and test incidents exist.

## Metrics rules

New directory: `backend/data/notifications/metrics/` — one file per rule group, rule name as top-level key.

```yaml
# metrics/qualcomm.yaml
qualcomm-weekly:
recipients:
- tsoni@quicinc.com
hardware: [qcs6490-rb3gen2]
origins: [maestro]
period_days: 7
```

Tree/hardware names must reference keys in `subscriptions/`; unknown names fail validation.

## Validation

- Pydantic models (consistent with `typeModels`)
- Test loads every file in `subscriptions/` and `metrics/`
- Equivalence test: resolved recipients per tree/notification type unchanged vs today
- Warn or fail on duplicate metrics recipients with overlapping scope across files
- CI must fail on invalid config

Update `docs/notifications.md` (community vs subscription delivery, examples).

## Acceptance criteria

- [ ] Schema documented with tree, hardware, and metrics examples
- [ ] Parser/validation tests; errors name file and field
- [ ] All existing subscription files load unchanged
- [ ] CI fails on invalid subscriber or metrics file

Start by inspecting the existing subscription files under backend/data/notifications/subscriptions/ and the Pydantic models used by typeModels. Then trace the current parser and CI validation tests before adding backend/data/notifications/metrics/ and updating docs/notifications.md. Done means all existing files load, invalid files fail CI with file and field errors, and recipient equivalence is tested.

Written by the indexing model from the issue text.