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/sdk/status.go

@@ -49,7 +49,7 @@ type KernelStatus struct {
 
 	// Scheduler 是输入调度器的运行时快照（可观测性，设计文档 §11 O1/O2）。
 	// M2 起输入不再直接排队在 channel 上，而是经 readyQueue/pendingInterrupts/
-	// suspendPool 三集合按优先级调度；这里把这些状态暴露出来。
+	// suspendStack 三集合按优先级调度；这里把这些状态暴露出来。
 	Scheduler SchedulerStatus `json:"scheduler"`
 }
 
@@ -57,10 +57,10 @@ type KernelStatus struct {
 type SchedulerStatus struct {
 	// Running 是当前执行的任务（空表示空闲）。
 	Running *SchedulerTask `json:"running,omitempty"`
-	// ReadyQueueDepth / PendingInterrupts / SuspendPool 是三个集合的深度。
+	// ReadyQueueDepth / PendingInterrupts / SuspendStack 是三个集合的深度。
 	ReadyQueueDepth   int `json:"ready_queue_depth"`
 	PendingInterrupts int `json:"pending_interrupts"`
-	SuspendPool       int `json:"suspend_pool"`
+	SuspendStack      int `json:"suspend_stack"`
 	MaxSuspendDepth   int `json:"max_suspend_depth"`
 
 	Enqueued  uint64 `json:"enqueued"`