## Summary

Adds the following API endpoints:
- GET rule by id
- GET rules (paginated)
- DELETE rule


### Checklist

- [x] [Unit or functional
tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)
were updated or added to match the most common scenarios

## Summary

This PR creates the `Logger`, `ESQL`, and `Storage` services to abstract
various functionality that is needed by the main components of the new
alerting engine.

### Out of scope
- Retries
- Error handling

### Checklist

Check the PR satisfies following conditions. 

Reviewers should verify this PR satisfies this list as well.

- [x] [Unit or functional
tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)
were updated or added to match the most common scenarios

---------

Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>

## Summary

> [!NOTE]
> Dear reviewers, this PR is getting merged into a feature branch. Only
the ResponseOps review is needed it at the moment. We will request for
your review when we open the feature branch PR to be merged on `main`.

This PR initializes all resources needed for the alerting new engine.

## Test
Ensure that the `.alert-events`, `.alert-transitions`, and
`.alert-actions` datastreams are created correctly, along with their ILM
policies. Also, ensure that restarting Kibana after the creation of the
datastreams do not produce errors.

Fixes: elastic/rna-program#72

### Checklist

Check the PR satisfies following conditions. 

Reviewers should verify this PR satisfies this list as well.

- [x] [Unit or functional
tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)
were updated or added to match the most common scenarios

---------

Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>

Keep upstream/main formatting and merge logCancelEvent addition
from the feature branch into the task cancel handler.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

…ule form duration fields (#258526)

## Summary

Adds maximum duration constraints to all duration fields in the alerting
v2 rule form, closing a validation gap where a direct API call could
submit arbitrarily large values that would pass server-side validation
undetected. Also enforces a minimum schedule interval and warns when the
lookback window is shorter than the execution interval.

**Problem:** Duration fields (`schedule.every`, `schedule.lookback`,
`state_transition.pending_timeframe`,
`state_transition.recovering_timeframe`) were only validated for format
correctness (e.g. `"5m"`, `"1h"`). There was no upper or lower bound, so
a malformed or malicious API payload could submit values like `"9999d"`
or `"1ms"` and they would be accepted by both the client and server.

**Solution:**

*Server-side (`@kbn/alerting-v2-schemas`):*
- Introduce `MAX_DURATION = '365d'` and `MIN_SCHEDULE_INTERVAL = '1m'`
constants in `constants.ts`
- Add `validateMaxDuration(value, max)`, `validateMinDuration(value,
min)`, and `parseDurationToMs(value)` to `validation.ts`, converting
duration strings to milliseconds for comparison
- Update `durationSchema` in `common.ts` to enforce `MAX_DURATION` on
every duration field automatically
- Add `scheduleEverySchema` in `rule_data_schema.ts` to additionally
enforce `MIN_SCHEDULE_INTERVAL` on `schedule.every`

*Client-side (`alerting-v2-rule-form`):*
- `ScheduleField` validates both min (`1m`) and max (`365d`) on
`schedule.every`
- `LookbackWindowField` validates max (`365d`) on `schedule.lookback`
and shows a plain-text help warning when the lookback is shorter than
the schedule interval
- `StateTransitionTimeframeField` validates max (`365d`) on
`pending_timeframe` and `recovering_timeframe`
- All client validation reuses the same functions from
`@kbn/alerting-v2-schemas`, keeping client and server in sync

The value `365d` was chosen to be intentionally generous: no legitimate
rule would need a schedule or timeframe exceeding one year. It is easier
to relax a constraint later than to introduce one after the fact (which
would be a breaking change for rules already storing larger values).

The decision for these changes has been captured in
[this](https://github.com/elastic/rna-program/blob/main/docs/decisions/2026-03-19-duration-field-validation-limits.md)
doc.

## Test plan

- [x] Unit tests pass for all modified files (128 tests across schema
and validation suites)
- [x] Dedicated `validation.test.ts` suite covering `parseDurationToMs`,
`validateMaxDuration`, and `validateMinDuration` including cross-unit
cases (`55w` exceeds `365d`, `500m` is within limit)
- [x] `schedule.every` rejects values below `1m` (e.g. `30s`, `59s`) and
above `365d` in both `createRuleDataSchema` and `updateRuleDataSchema`
- [x] `schedule.lookback`, `pending_timeframe`, and
`recovering_timeframe` reject values exceeding `365d`
- [ ] Manually verify: enter `30s` in Schedule field and confirm min
error appears
- [ ] Manually verify: enter `9999d` in Schedule / Lookback / Pending
timeframe / Recovering timeframe fields and confirm max error appears
- [ ] Manually verify: set Lookback window shorter than Schedule
interval and confirm warning text appears below the field

---------

Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>

Reverts the notification policy mapping/schema/test changes from 49f1ce6
while preserving the alerting_rule mapping fixes that align with the
model version create schema (recovery_policy, no_data, artifacts).

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>