🟡 Medium Priority

改动位置：src/lualib/mctp_discovery.lua:155，把 self:set_discovered(false) 从"应答之后"移到"应答之前"。

失败链：set_discovered(false) 同步触发 on_discovery_changed:emit(false)（mctp_discovery.lua:82-89；signal 为同步派发，mctp_app.lua:145 需显式 next_tick 才能延后，可佐证），监听者调用 self.mctp_engine:reset()；c_mctp_engine:reset()（mctp_engine.lua:311-321）先执行 self.owner_eid = 0; self.bmc_eid = 0; self.bmc_phy_addr = 0，之后才轮到第 158 行的 self.ep:response(...)。

问题：第 156 行 set_owner_eid(eid, phy_addr) 只恢复了 owner，bmc_eid/bmc_phy_addr 没有恢复。而 c_ep_mctp_ctrl:response（ep_mctp_ctrl.lua:57-59）用 mctp_ctx.src = self.mctp_engine.bmc_eid、dest = owner_eid 组帧，add_pcie_vdm_ctx 又写 pcie_vdm_ctx.bmc_phy_addr = mctp_engine.bmc_phy_addr。于是在重发现（discovered 原为 true）场景下，本条 PrepareForEndpointDiscovery 应答的源 EID 变成 0、bmc_phy_addr 变成 0；改动前应答在 reset 之前组帧，携带的是上一轮已分配的 bmc_eid/bmc_phy_addr。对端若按 src EID/phy_addr 校验或路由，握手应答可能被丢弃，重发现停在握手阶段。

测试 test_rediscovery_cancels_old_work_but_sends_control_response（test/unit/test_write_service.lua:363-386）只断言 #f.writes == 1，未校验写出帧头的 src/phy_addr，覆盖不到该差异。

建议：在 set_discovered(false) 触发 reset 前保存 bmc_eid/bmc_phy_addr，reset 后用请求中的值恢复；或让 control 应答改用请求携带的 src/phy_addr 组帧，避免应答帧 src EID=0、bmc_phy_addr=0。

💡 建议：send 的计数与"延迟写入失败"语义需对齐

send 仅在 tx_admission_failed（准入/容量拒绝，同步返回）时递增 not_send_count 并抛错；但消息已准入、后续 drain 阶段驱动写入失败的场景（on_tx_complete 回调、wait.err）发生在返回之后，send 仍会走 req_success_count = req_success_count + 1，把该次发送计为成功。

PR 说明已声明"旧 Send 返回只表示提交/准入，不表示对端已收到"，语义上是合理的；但两个计数口径（准入 vs 写入）混在一起，实机上排查"已提交但未送达"时容易误读。 修复建议：在注释中明确 req_success_count 为"准入成功"而非"写入成功"，或在 on_tx_complete 上单独维护写入失败计数。

🟡 Medium Priority

改动位置：src/lualib/mctp_endpoints/ep_mctp.lua:121-124，c_ep_mctp:send 在 cb() 后若 tx_admission_failed 为真则 error('MCTP transmit queue full')。

契约变化：send 之前从不出错，现在会抛异常。所有子类端点都是 super.send(self, function() ... end) 之后紧跟收尾动作，异常会让收尾动作整段跳过。

失败模式（具体）：ep_nvme.lua:134-137 为 c_nvme_endpoint.super.send(self, function() ... end) self:release_cmd_slot(slot) 一旦 PCIe 队列准入失败（control 8 / request 16 / response 40 配额或 16KiB 字节上限打满），super.send 抛出 MCTP transmit queue full，release_cmd_slot(slot) 不再执行，NVMe 命令槽被永久占用；多次准入失败后该消息类型可用槽耗尽，后续发送全部失败（发送路径不可恢复）。同理，ep_spdm/ep_pldm/ep_ncsi 的调用方（mctp_mdb_mgmt.lua:120 return ep:send(ctx, data, req_ctx) 与 mctp_app 的 ImplEndpointPCIeEndpointSend）都没有 pcall 包裹，异常会直接冒泡到业务侧，把"队列满"变成一次异常回包而不是可判断的返回值。

建议：把 admission 失败改为返回值或让调用方保证清理：send 内不要直接 error，改为 return false, 'MCTP transmit queue full'；或让所有子类 send 用 pcall 包裹 super.send，确保 release_cmd_slot 等收尾动作在异常路径下也执行。

🔵 Low Priority

变更行：89 行新增 self.on_tx_complete = signal.new()，237 行每次完成都 emit。

影响：在整个 src 中检索 on_tx_complete 只有 88-89 行的定义与 237 行的 emit，没有任何生产代码订阅（仅 test/unit/test_write_service.lua 的用例订阅）。因此"写入失败/取消/过期"这些新增回传除了置 wait.err 之外没有任何可观测出口：例如 Control 应答（Prepare for Discovery）被容量拒绝时，既无监听者统计也无上层处理，信号实际为死代码。

可选改进（非必须）：要么删除该信号，要么在 ep_mctp/ep_mctp_ctrl 的发送侧订阅并把失败计入已有的 not_send_count/req_error_count 类计数，让这项回传真正被消费。

建议：确认该信号是否真有消费方：若无，删除 on_tx_complete 定义与 237 行的 emit；若有，补上订阅点（例如在端点发送侧统计写入失败次数），并在本 PR 内一并提交，避免新增无人使用的对外接口。

🔵 Low Priority

变更行：201-204 行在每帧（每个分片）回调里都 mctp.mctp_ctx.new() + mctp.pcie_vdm_ctx.new() 并从 ctx 拷贝，另外 210 行每帧 table.concat 生成 meta.key。

影响：这是 PCIe 出口最热的路径（PLDM/NCSI/SPDM 业务每一帧都会经过），每条消息的每个分片都构造两个 C++ ctx 对象并做两次 copy_from；同文件 542 行 rx 明确用模块级单例 mctp_ctx 复用来规避这种开销，两边做法不一致。

建议：续帧（som == false）不需要重新拷贝上下文：或只在 som 帧构造 transport/physical 并在同一消息内复用，或把 valid 需要的标量（remote_phy_addr、bmc_phy_addr、src、dest、tag）提取为数字/字符串存入 meta，避免每帧两个 ctx 对象分配。

🟡 Medium Priority

变更行：done 在失败且命中原始 wait 时执行 wait.err = errors.invalid_mctp_request(); skynet.wakeup(wait.co)（232-236 行）。

受影响契约：request() 里 wait_info 在 pcall(cb, key) 之前就登记进 rsp_wait_list，而 cb 内部（ep_mctp/ep_mctp_ctrl → mctp_proto:push → 本 tx handler）在容量不足时通过 243-247 行同步回调 meta.done(false, 'capacity')。本 diff 新增的 492 行 if not ok or wait_info.err 正是为了处理这种"cb 未返回错误但等待对象已被置错"的同步场景，说明该路径确实存在。

失效模式：此同步路径下 wait.co 就是 coroutine.running()（该协程还没走到 510 行的 skynet.wait()），对正在运行/尚未挂起的协程调用 skynet.wakeup 属于非法唤醒，skynet 侧会出现 cannot resume non-suspended coroutine 或误唤醒调用者；触发条件正是本 PR 的目标场景——PCIe requester 消息在队列水位满/单条消息字节超限时被拒。此外多分片消息被拒时，后续每个分片（entry 为 nil 的分支）都会再回调一次 done，对同一 wait 反复唤醒。修复只需在该场景下不唤醒（492 行已经能返回 E_SEND_FAILED），或改为延迟唤醒。

建议：在登记 wait 时记录其所属协程/挂起状态（如 wait.co == coroutine.running() 时不 wakeup），或在 done 中判断 coroutine.status(wait.co) == 'suspended' 后再唤醒，并依赖 492 行的 wait_info.err 检查让同步路径直接返回 E_SEND_FAILED；也可将唤醒改为 skynet.fork 延迟执行，避免在 push 调用栈内唤醒正在运行的请求协程。

🟡 Medium Priority

变更行：243-247 行在 enqueue 返回未准入且未通知时直接调用 meta.done(false, 'capacity')。

受影响契约：队列内部的完成通知统一走 notify() 的 pcall(entry.meta.done, ok, reason)（mctp_tx.lua:51-55），因此使用者回调抛错被隔离；引擎自己在 246 行却无保护地直调同一个 done。

建议：将 246 行的直接回调改为受保护调用（例如 pcall(meta.done, false, 'capacity')），与 mctp_tx 内部 notify 的隔离方式保持一致，避免回传逻辑（错误模块缺失、非法唤醒、on_tx_complete 订阅者异常）影响协议栈的发送流程。

🔵 Low Priority

变更行：492-496 行新增 if not ok or wait_info.err 分支，是本次"写入结果回传"落到请求方的核心分支。

失效模式：test/unit/test_write_service.lua 里的引擎用例只用手工构造的 wait = { co = ... } 直接断言 wait.err（如 test_engine_batches_real_encoded_fragments_and_reports_write_failure），从未真正走 c_mctp_engine:request()。因此"cb 成功但 wait 已被置错时返回 E_SEND_FAILED"、"正常完成时返回 E_OK"、"置错后 rsp_wait_list[key] 被清理"这些行为都没有回归保护：例如有人把 wait_info.err 的判断挪到 skynet.wait() 之后、或改成返回 E_ERROR，测试仍然全绿，而现场表现是队列满时请求一直等到 15s 默认超时而不是快速失败。

建议：补一条针对 request() 的用例（可把 skynet.wait/skynet.wakeup 打桩）：cb 内同步触发一次发送失败，断言 request() 返回 E_SEND_FAILED 且 rsp_wait_list[key] 已清空、未创建定时器；再补一条 cb 成功且被准入时返回 E_OK 的正向用例。

⚠️ 警告：阻塞式 skynet.call 写驱动可能导致整个发送队列永久卡死

默认 self.write 使用 skynet.call('.mctp_write_service', ...)（阻塞等待响应），而 drain() 只在单个 fork 出的协程中运行，且 add_frame 用 if not self.running 避免重复启动 drain（见 line 168-173）。

风险：若底层 mctp.write 因驱动繁忙/挂起长时间不返回，write_service 不会 skynet.ret，则该 drain 协程被永久挂起，self.running 保持 true，此后所有新排队消息都无法被调度，发送通路整体不可用。

并且 100ms deadline 的 reason 检查只发生在两次写之间（drain 内 for 循环中逐帧后检查），无法在一帧阻塞式写执行过程中打断它，所以 deadline 并不能兜底驱动挂死。

修复建议：

• 若驱动阻塞是真实风险，建议使用非阻塞/带超时的写入（或在 write_service 侧对 mctp.write 增加异步超时/看门狗），并让 drain 在写入被卡住时仍能通过其他协程主动退出；
• 或者明确约定驱动 write 必须非阻塞，并在文档/注释中记录该前提。

🔵 Low Priority

改动位置：src/lualib/mctp_tx.lua:100-119（Queue:drain），以及 133-150（add_frame 里 som 建立 partial 后需等 eom 才进入 ready）。

问题 1（drain 无异常兜底）：self.running = false 只在 while 循环正常退出时执行，self.active 也只在每轮末尾清空。循环体内 local reason = self:reason(entry) 未被 pcall 保护，而 reason 内部会调用 self.now()（默认实现 clock.monotonic_time()，见第 25-29 行）并读取 entry.meta.deadline。一旦 now()/时钟实现异常或 deadline 缺失（例如外部直接构造 meta 而漏填），drain 会带着 running=true、active=非nil 退出，此后 add_frame 第 167 行 if not self.running 永远为假，再也不会 fork 新的 drain —— 整条 PCIe 发送通道永久停摆且无任何日志。触发条件是一次异常；后果是静默全局卡死，属于比"单条消息失败"严重得多的故障模式。

问题 2（partial 无回收路径）：som 帧被接纳后容量计入 used[1]/self.count，但只有 eom 到达才会移入 ready 并被 drain 回收。若该消息中途终止（后续帧因 #frame == 0/类型不符在 136-138 行被拒，或上层 push 中断），self.partial[owner] 会一直持有 1 个消息配额与相应字节数；100ms deadline 只作用于 ready 中的条目，partial 没有超时扫描，只能等同 owner 的下一条 som 覆盖或 cancel。触发后 control(8)/request(16) 配额被长期占用，可能让该 System 的请求类报文持续 admission 失败。

建议：drain 主体用 pcall/xpcall 包裹，并在无论成功失败都清理 self.active 与 self.running（finally 语义）；同时为 partial 中的半成品消息增加 deadline 回收，避免配额长期泄漏导致后续 admission 一直失败。