[Notifications] PromQL subset compiler and default rule templates

The compiler that takes user-authored PromQL or template values and produces the rule that vmalert actually loads. This is the load-bearing security boundary for multi-org isolation.

Checklist:

- [ ] New package `server/internal/domain/notifications/compiler` parses with `github.com/prometheus/prometheus/promql/parser`.
- [ ] Allowlist: vector selectors, aggregations, `rate`, `increase`, comparison and basic arithmetic binary ops. Reject subqueries, MetricsQL extensions, and any function not on the list.
- [ ] Reject any vector selector whose metric name is outside the `fleet_` namespace.
- [ ] For every vector selector, inject `organization_id=""` into the matchers, replacing any user-supplied value of the same label.
- [ ] After aggregations and binary ops re-inject `organization_id` onto the emitted alert labels via the rule's `labels:` block, since aggregations can drop labels.
- [ ] Built-in templates `Offline`, `Hashrate`, `Temperature` (`sensor_kind` aware), `Pool`, `Command failure` render to PromQL that runs through the same compiler. No parallel path that bypasses org injection.
- [ ] Defaults shipped via `server/internal/domain/notifications/defaults` and seeded into the rules table for every organization (idempotent backfill on existing orgs).
- [ ] Unit tests: function not allowed, metric outside namespace, attempted org spoofing, label injection survives `sum by (device_id)`. Snapshot tests for every template's compiled output.