fix(scheduler)!: 中断栈语义（嵌套抢占 LIFO），并修掉抢占空转

用户指正：存在**中断被中断**的场景，所以被打断的现场要进**中断栈**。
我此前把 suspendPool 明确写成“不是栈、按优先级取”，是错的。

改动：
- suspendPool 改名 suspendStack，恢复纪律改为**严格 LIFO（只比栈顶）**；
  栈内不做优先级重排——嵌套抢占天然使栈自底向上基础级递增，
  且“后被打断的先恢复”才是栈语义。取出即弹栈。
- 修掉一个由此暴露的真 bug（抢占空转）：一次抢占生效后，被挂起的原任务
  会因饥饿防护提升有效级，与抢占者同级；此时若按“先到先服务”，原任务
  （入队更早）会被立刻选回，抢占者永远排不到 —— 抢占等于没发生。
  现在**同级时 pendingInterrupts 优先于其它两类**，保证抢占必然生效。
- 状态 DTO：SuspendPool/suspend_pool → SuspendStack/suspend_stack
- 设计稿：§2 用语更正（它**就是**中断栈）、§4.1 选择函数（候选只含栈顶 +
  pending 同级优先，并说明为何必需）、§6.2/§6.3/§9/§11 用例同步

测试新增 scheduler_stack_test.go 3 项：
- 嵌套 L1→L2→L3，恢复严格 LIFO（B 先于 A）
- 只比栈顶：人为构造“栈底 L3、栈顶 L2”，必须取栈顶（区分两种实现）
- 嵌套下的深度上限

验收：agent 全量 + -race；全仓 build/vet 通过

internal/agent/core/task.go

@@ -6,7 +6,7 @@ package core
 //
 // M1 只做一件事：把原先「一个 425 行的 process() 大函数」拆成
 // **显式 step 游标 + TaskFrame**。目的不是加能力，而是让「现场」变成数据——
-// 之后 M3 才能把帧存进 suspendPool 并在安全点恢复。
+// 之后 M3 才能把帧存进 suspendStack 并在安全点恢复。
 //
 // 行为等价的判据：既有全部 agent 测试通过，且 R3/X3（见设计文档 §11）通过。
 //