🔵 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

新增行 local typ, versions = req.req_data:byte(1)（mctp_discovery.lua:177）：string.byte 多返回值语义使 versions 取到的是请求第 2 个字节，而其余分支又把 versions 当作"版本列表字符串"参与 #versions // 4 与字符串拼接。

证据链：正常路径下 control_rx_handler 已用 REQUEST_LENGTH[4] = 1 保证 payload 恰为 1 字节，此时 byte(1) 只返回一个值、versions 为 nil，因此暂时不炸；但 version_response 是公开方法，一旦被其它入口（如后续 Control 分发改造、直接单测/复用）以 2 字节以上 payload 调用，typ 落在 0/255/(1 且已注册) 之外时，versions 会是第 2 个字节的数字（Lua 中 0 也是真值），随后执行 #versions 直接抛 attempt to get length of a number value，请求处理协程报错、该请求得不到任何响应。

失败模式：payload 长度 >1 且 message type 不受支持 ⇒ 运行时异常而非按 DSP0236 回 0x80。同时该赋值语义上具误导性（versions 既表示"第 2 字节"又表示"版本串"）。

建议：只取第一个字节并显式声明版本串变量，例如 local typ = req.req_data:byte(1) + local versions，消除把数字当字符串长度的隐患。

🟡 Medium Priority

变更行（mctp_discovery.lua:171-173、235、184）新增 has_pldm_responder()，读取 self.mctp_engine.pldm_responder.reg_count，并据此决定 Get Message Type Support 返回 '\1\1'（支持 PLDM）还是 '\0'（不支持），以及 Get MCTP Version Support(type=1) 返回 0x80 还是 DSP0241 绑定版本。

证据链：在 src 全量 grep pldm_responder|reg_count，除本文件的读取处外没有任何赋值/注册代码（src/lualib 下 mctp_engine.lua、ep_pldm.lua、mctp_mdb_mgmt.lua 均无该字段）；单测中也是测试手工写入 self.engine.pldm_responder = { reg_count = 1 }（test/unit/test_discovery.lua:163）才使该分支成立。

失败模式：生产环境 pldm_responder 恒为 nil ⇒ Get Message Type Support 永远回 "0 个消息类型"，Get Version Support(type=1) 永远回 0x80 不支持。请求方（Host 固件/其它端点）据此判定 BMC 无 PLDM 能力而放弃 PLDM 建链，PR 声称的"按实际已注册的 PLDM responder 动态上报能力"实际不可达；单测覆盖的是生产不可能出现的状态，形成"测试绿、功能哑"的假阳性。另外若将来有人写入一个不含 reg_count 的表，responder.reg_count > 0 会抛 nil 比较异常（该路径也被本次新增的 1Hz 身份/查询路径直接暴露）。

建议：在真正登记 PLDM responder 的位置（如 mctp_endpoints/ep_pldm.lua 或 mctp_engine 的 endpoint 注册/释放回调）维护 mctp_engine.pldm_responder（至少含 reg_count），并在 has_pldm_responder 中对 reg_count 做类型判断（type(responder.reg_count) == 'number' and responder.reg_count > 0）；若本轮确实无法接入登记源，则应先固定返回"不支持"，并在 PR/注释中明确该能力暂不可用，避免单测伪造不存在字段。

🔵 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 调用。