用途：在 Kibana 插件中注册并调度后台任务。任务类型在插件 setup 阶段通过 taskManager.registerTaskDefinitions({ [type]: definition }) 注册，定义静态元数据（timeout、cost、priority、maxAttempts、schemas）与 createTaskRunner 工厂；调度通常在 start 阶段用 ensureScheduled（周期性、幂等）或 schedule / bulkSchedule（一次性）。
主要能力与要点：timeout 必须显式设置，默认 '5m' 未必合适；createTaskRunner 应解构并传播 signal（AbortSignal）到 ES、HTTP 与循环，循环中检查 signal.aborted；cancel() 可选，仅在需释放信号无法覆盖的资源时实现，超时时由 Task Manager 调用，关闭时不调用；错误须用 throwUnrecoverableError（永久失败）或 throwRetryableError（瞬时失败）分类；有参数时定义 paramsSchema 在调度时校验；run() 返回非空 state 时须定义 stateSchemaByVersion 并提供纯且幂等的 up 迁移；maxAttempts: 1 用于不应重试的任务；cost 按实际资源占用选择（Tiny=1、Normal=2、Large=4、ExtraLarge=10），priority 默认 Normal 通常正确；注意 TaskCost（整数枚举）与 InstanceTaskCost（字符串枚举，用于序列化场景）的区别，后者用 getTaskCostFromInstance 转换。
使用方式：周期性任务在插件 start 用 ensureScheduled 并传稳定 id，避免每次重启重复创建；用户触发的一次性任务用 schedule / bulkSchedule；若用户可能改过调度，先 get 现有任务再保留其 schedule/params/state。新增任务类型需同步更新 check_registered_task_types.ts 中的断言数组（手工编辑并保持排序）。
限制：资料未提供具体版本、安装命令、收费或平台信息；validator 只校验 timeout 格式不校验合理性；state 迁移 up 必须纯且幂等；首次调度传入的 state 必须符合 v1 schema。