Actuator 少了 Redis 健康项：检查自定义扩展的响应式注册表

Servlet 应用的 Actuator 健康端点里没有 Redis，但容器中已经创建了响应式 Redis 健康贡献器。若应用或公共库自定义了 HealthEndpointWebExtension，先检查扩展构造时传入的注册表，不要立刻排除 Redis 响应式健康自动配置。

Spring Boot 4.1.0 有过这一明确场景：自定义扩展没有传入有效的 ReactiveHealthContributorRegistry。响应式贡献器存在于容器里，却没有进入这条自定义端点的收集路径；补上正确注册表后才恢复显示。

Servlet 应用也可能有响应式 Redis 工厂

是否创建响应式 Redis 健康项，取决于类路径、启用条件和 ReactiveRedisConnectionFactory 等 Bean。它并不简单等同于“整个 Web 应用必须是响应式”。Lettuce 的连接工厂可以同时实现命令式与响应式接口，因此 Servlet 模式下出现响应式贡献器并不自动构成异常。

检查实际 Bean 与条件装配结果，再查看自定义健康扩展的配置。若 Redis 贡献器根本没有创建，应先查连接工厂和健康项开关；如果已经创建，继续查扩展和注册表之间的连接。健康详情的显示权限和健康组过滤也会影响可见结果，应按已有授权访问管理端点，不为排错把完整健康信息暴露到公网。

自定义扩展应保留两条贡献路径

在 Boot 4.1.0 的接口中，HealthEndpointWebExtension 构造器既接收命令式 HealthContributorRegistry，也接收可空的备用 ReactiveHealthContributorRegistry。传 null 本身可以满足类型签名，但有响应式贡献器需要汇入时，会遗漏这一组结果。

修改创建扩展的那一个配置入口，让它使用应用实际装配的响应式注册表，同时保留健康组和慢贡献器日志阈值等参数。不要为了让构造器通过，手工新建一张没有任何贡献器的空表。项目跨 Boot 版本维护时，应以对应版本的构造器和注册流程为准，避免照抄旧版签名。

排除 DataRedisReactiveHealthContributorAutoConfiguration 可能让另一种健康项接管，从而暂时看见 Redis，但它改变了被收集的贡献器，不能修正自定义扩展漏接注册表的原因。仅在应用明确选择另一套连接与健康机制时，才按设计调整自动配置。

验收从原来的管理端点和健康组入口检查 Redis 结果，并覆盖可控的正常连接与故障状态。确认不只容器里有 Bean，端点也确实使用它的健康结果；同时检查原有其他命令式和响应式健康项均保持，访问权限没有被放宽。