🔵 Low Priority

新增的 init 分支（mctp_discovery.lua:82-92）用 c_tasks.get_instance():new_task('mctp_identity'..system_id):loop(...) 注册每 1000ms 执行一次的后台任务，但循环体只有 if not self.endpoint_uuid then self:load_endpoint_identity() end，成功后没有任何 :stop()/返回终止逻辑，self.identity_task 也从未在其它地方被引用（全仓仅此一处赋值）。

证据链：同类任务 start_update_route_table/start_smbus_eid_poll_task 均有显式 stop 入口（stop_update_route_table 等），而身份任务没有；且 update_os_power_status(false) → set_discovered(false) → on_discovery_changed 只做 mctp_engine:reset() 与 stop_update_route_table()，不会停止身份任务。

失败模式：身份一旦加载成功，该任务仍按 1Hz 永久唤醒（每个 system 一个），空转消耗 skynet 定时器与调度；系统下电/复位也不会停止，属于长期存在的后台空转任务。功能上不致命，但属于本次新增的可靠性/资源浪费点。

建议：在循环体内于身份加载成功后停止任务，例如 if self.endpoint_uuid then self.identity_task:stop(); return end，并在 update_os_power_status/mctp_engine:reset() 路径中一并停止或重启该任务，避免永久空转。

🔵 Low Priority

新增的 load_endpoint_identity（mctp_discovery.lua:132-168）用 local ok, loaded = pcall(...) 包裹整段 DBus 取 UUID 逻辑，但失败时把 pcall 返回的错误对象完全丢弃：日志固定为 '[System%s]MCTP endpoint identity is not ready' 且级别是 log:debug，并用 identity_warned 只打印一次。

证据链：该函数是 endpoint_uuid 的唯一生产来源（Get Endpoint UUID 直接依赖它，未就绪即回 NOT_READY），而其中包含两套不同调用面——先是 bus:timeout_call(...) 调 bmc.kepler.Mdb.GetSubObjects，随后是 bus.bus:timeout_call(...) 调 GetAllWithContext（同一对象两种访问路径）。任一处签名/字段名（如 bus.bus、GetSubObjects 的 a{ss}sias 入参、values.UUID:value()）与实际框架不符，都会被 pcall 静默吞掉。

失败模式：只要该调用面与真实框架有偏差，Get Endpoint UUID 将永久返回 NOT_READY，而现场只有一条 debug 级、无错误详情的日志，无法定位是对象不存在、存在歧义还是 API 不匹配；默认日志级别下等同于完全静默。

建议：把 pcall 的第二个返回值保存下来（local ok, err = pcall(...)），首次失败时用 info/warn 级别记录 err（后续重试仍可保持仅一次），便于现场判断是对象缺失/多实例还是 DBus API 不匹配。

🔵 Low Priority

新增的核心行为"后台有界读取掉电保存的 Assembly.UUID"依赖 init() 中 if self.mctp_engine.bus then ... new_task('mctp_identity'..system_id):loop(...):set_timeout_ms(1000) end 这段接线（mctp_discovery.lua:82-92）：它是在生产环境中给 endpoint_uuid 赋值的唯一入口，没有它 Get Endpoint UUID 永远回 NOT_READY。

证据链：新增测试 TestMctpControlAdmission:setup 用 c_mctp_engine.new(nil, 1) 构造（bus == nil），identity 分支被跳过；test_identity_discovery_retries_and_freezes_valid_device_uuid（test/unit/test_discovery.lua:177-234）是在构造之后直接调用 load_endpoint_identity()，并且 make_fake_task 的 loop() 直接返回而不执行循环体（test/unit/test_discovery.lua:26-28）。

失败模式：若 init() 中的任务注册写错（任务名重复、loop 回调签名不匹配、set_timeout_ms 调用顺序变化）或该分支被漏掉，endpoint_uuid 在生产中永远为 nil，而 114 个单测仍全绿，回归完全不可见。PR 自验证报告也承认"后台身份任务的注册/自动重试接线尚待实际部署验证"。

建议：补一个用例：用带 bus 的 engine 构造 discovery（stub c_tasks.get_instance 记录被创建的任务名与 set_timeout_ms 参数，并让 fake task 的 loop 捕获回调），断言 init 后存在名为 mctp_identity<system_id> 的任务、超时 1000ms，且手动执行一次回调后 endpoint_uuid 被写入、再次执行不会再发 DBus 调用。