update dispatcher readme to use new terminology

Author: baileycash-elastic

x-pack/platform/plugins/shared/alerting_v2/server/lib/dispatcher/README.md

@@ -10,7 +10,7 @@ It runs on its own Task Manager schedule, separate from per-rule execution.
 
 - Loading candidate alert episodes for the current execution window
 - Applying suppression semantics from alert actions
-- Matching episodes to notification policies
+- Matching episodes to action policies
 - Grouping matched episodes
 - Throttling repeated delivery
 - Dispatching to destinations
@@ -55,7 +55,7 @@ The pipeline then moves through these phases:
 2. Fetch suppression facts
 3. Split into dispatchable vs suppressed episodes
 4. Load rule metadata for dispatchable episodes
-5. Load enabled notification policies
+5. Load enabled action policies
 6. Evaluate policy matchers
 7. Build notification groups
 8. Apply throttling
@@ -71,7 +71,7 @@ By the end of a dispatcher run, every episode that reached the later pipeline st
 | `dispatch` | The episode matched a policy, survived suppression and throttling, and was selected for delivery. | `fire` per episode, plus `notified` per notification group |
 | `throttled` | The episode matched a policy, but the notification group was held back by throttling. | `suppress` with a throttle-related reason |
 | `suppressed` | The episode was explicitly filtered out by suppression logic such as ack, snooze, or deactivate semantics. | `suppress` with the suppression reason |
-| `unmatched` | The episode remained dispatchable but matched no enabled notification policy. | `unmatched` |
+| `unmatched` | The episode remained dispatchable but matched no enabled action policy. | `unmatched` |
 
 The full action taxonomy, including user-written actions such as `ack` and `snooze`, is documented in [`../../resources/README.md`](../../resources/README.md).
 
@@ -113,9 +113,9 @@ Unlike the rule executor, the dispatcher is not streaming. Each step receives on
 - `continue` with a partial state merge, or
 - `halt` with a `DispatcherHaltReason`
 
-## Notification policy model
+## Action policy model
 
-A notification policy is a saved object scoped to a Kibana space. Policies are not embedded into the rule. Instead, the dispatcher loads enabled policies for the space and evaluates each policy against the candidate episodes.
+An action policy is a saved object scoped to a Kibana space. Policies are not embedded into the rule. Instead, the dispatcher loads enabled policies for the space and evaluates each policy against the candidate episodes.
 
 Each policy defines:
 
@@ -148,7 +148,7 @@ The dispatcher carries state forward through `DispatcherPipelineState` in `types
 | `suppressions` | `FetchSuppressionsStep` | Suppression facts from `.alert-actions`. |
 | `dispatchable` / `suppressed` | `ApplySuppressionStep` | Split of episodes that may continue vs those that must not notify. |
 | `rules` | `FetchRulesStep` | Rule metadata keyed by rule id. |
-| `policies` | `FetchPoliciesStep` | Enabled notification policies keyed by id. |
+| `policies` | `FetchPoliciesStep` | Enabled action policies keyed by id. |
 | `matched` | `EvaluateMatchersStep` | Concrete `(episode, policy)` matches. |
 | `groups` | `BuildGroupsStep` | Notification groups to consider for delivery. |
 | `dispatch` / `throttled` | `ApplyThrottlingStep` | Groups that may send now vs groups held back. |
@@ -163,9 +163,9 @@ Step order is defined in `setup/bind_dispatcher_executor.ts`.
 | 2 | `FetchSuppressionsStep` | Load alert-action facts needed for suppression decisions. |
 | 3 | `ApplySuppressionStep` | Mark each episode as dispatchable or suppressed, preserving reasons. |
 | 4 | `FetchRulesStep` | Load rule metadata for the remaining dispatchable set. |
-| 5 | `FetchPoliciesStep` | Load enabled notification policies for the space. |
+| 5 | `FetchPoliciesStep` | Load enabled action policies for the space. |
 | 6 | `EvaluateMatchersStep` | Evaluate each policy matcher against each episode context. |
-| 7 | `BuildGroupsStep` | Build `NotificationGroup` objects based on policy grouping settings. |
+| 7 | `BuildGroupsStep` | Build `ActionGroup` objects based on policy grouping settings. |
 | 8 | `ApplyThrottlingStep` | Compare candidate groups with notification history and split them into dispatch vs throttled. |
 | 9 | `DispatchStep` | Perform delivery side effects for eligible groups. |
 | 10 | `StoreActionsStep` | Persist the execution outcome to `.alert-actions`. |
@@ -256,11 +256,11 @@ export interface DispatcherPipelineState {
   readonly dispatchable?: AlertEpisode[];
   readonly suppressed?: Array<AlertEpisode & { reason: string }>;
   readonly rules?: Map<RuleId, Rule>;
-  readonly policies?: Map<NotificationPolicyId, NotificationPolicy>;
+  readonly policies?: Map<ActionPolicyId, ActionPolicy>;
   readonly matched?: MatchedPair[];
-  readonly groups?: NotificationGroup[];
-  readonly dispatch?: NotificationGroup[];
-  readonly throttled?: NotificationGroup[];
+  readonly groups?: ActionGroup[];
+  readonly dispatch?: ActionGroup[];
+  readonly throttled?: ActionGroup[];
   readonly myNewMetadata?: string;
 }
 ```
@@ -311,7 +311,7 @@ describe('MyNewStep', () => {
 
 If you are not adding a new pipeline phase, but instead want to support a new delivery target, start with:
 
-- `types.ts` to extend `NotificationPolicyDestination`
+- `types.ts` to extend `ActionPolicyDestination`
 - `steps/dispatch_step.ts` to add the new dispatch branch
 - any saved object / route validation that defines allowed destinations