[Alerting V2] Document "recover" no-data strategy resolves immediately, ignoring recovery delay

### Description

What: `no_data_strategy: 'recover'` on Alerting v2 rules now resolves the alert episode **immediately** to `inactive` on the first no-data run — regardless of the configured `recovery_strategy`, and ignoring any `recovering_count`/`recovering_timeframe` recovery-delay settings. Previously it routed through the recovery FSM (`active → recovering → inactive`) and inherited the recovery delay.

When: Shipped in Kibana #285459, targeted for 9.6.0.

Why: The old behavior meant a "recover on no data" rule could take multiple runs to actually close, with timing that depended on unrelated recovery-delay config — this was surprising and the root cause of a real incident (Rootly 3361, "v2 alerts may not recover"). The UI label for this option also changed from "Recover" to "Recover immediately" to make the behavior explicit.

### Resources

This feature was implemented in https://github.com/elastic/kibana/pull/285459.

The decision-logic reference (internal design doc, not public docs) was updated in https://github.com/elastic/rna-program/pull/910.

Root-cause issue: https://github.com/elastic/rna-program/issues/775.

### Which deployment methods does this change impact?

Elastic On-Prem and Cloud (all)

### Feature differences

The feature is identical in all deployment methods.

### What Elastic Stack release is this request related to?

9.6

### Serverless release

_No response_

### Collaboration model

The documentation team will create the first draft

### Point of contact.

**Main contact:** @baileycash-elastic

**Stakeholders:**
@doakalexi
@tiamliu