[Notifications] Storage: rules, channels, and encrypted secrets

Persist rules and channels in the ProtoFleet database with the metadata the design calls out, and route channel secrets through the existing encrypt service.

Checklist:

- [ ] Migration `server/migrations/000038_create_notification_tables.{up,down}.sql`.
- [ ] `notification_channels`: `id`, `organization_id` (NOT NULL, FK), `kind` (`email|webhook`), `name`, `config_jsonb`, `secret_ref`, `version`, timestamps, owners. Unique on `(organization_id, name)`.
- [ ] `notification_rules`: `id`, `organization_id`, `template_kind` (`offline|hashrate|temperature|pool|command|custom`), `name`, `scope_jsonb`, `expression_text`, `compiled_expression_text`, `validation_status`, `validation_error`, `version`, timestamps, owners.
- [ ] `notification_config_state` (single row) holds the monotonic generation counter for the reload pipeline.
- [ ] sqlc queries under `server/sqlc/`; new domain package `server/internal/domain/notifications/stores` with `interfaces` + `sqlstores` matching the existing pattern. Every CRUD method takes `organizationID` and refuses zero values.
- [ ] Webhook bearer headers and SMTP passwords stored only as `secret_ref` strings; ciphertext lives in the encrypt service.
- [ ] Read paths zero the secret field and set a boolean `has_secret`. Delete also deletes the secret in the encrypt service.
- [ ] Tests: row created in org A invisible to org B; no API response, log line, or activity entry contains cleartext secret.