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/scheduler_e2e_test.go

@@ -42,14 +42,14 @@ func waitQuiescent(t *testing.T, a *Agent, wantExecuted uint64, timeout time.Dur
 	for {
 		snap := a.DumpScheduler()
 		if snap.Running == nil && len(snap.Queue) == 0 &&
-			len(snap.PendingInterrupts) == 0 && len(snap.SuspendPool) == 0 &&
+			len(snap.PendingInterrupts) == 0 && len(snap.SuspendStack) == 0 &&
 			snap.Stats.Executed >= wantExecuted {
 			return snap
 		}
 		if time.Now().After(deadline) {
 			t.Fatalf("未在 %v 内排空：running=%v queue=%d pending=%d suspend=%d executed=%d",
 				timeout, snap.Running != nil, len(snap.Queue), len(snap.PendingInterrupts),
-				len(snap.SuspendPool), snap.Stats.Executed)
+				len(snap.SuspendStack), snap.Stats.Executed)
 		}
 		time.Sleep(20 * time.Millisecond)
 	}
@@ -147,7 +147,7 @@ func TestObservability_SchedulerEventsAndStatus(t *testing.T) {
 
 	// 状态快照（供状态页/诊断）：计数一致、三集合为空。
 	st := a.GetKernelStatus().Scheduler
-	if st.SuspendPool != 0 || st.PendingInterrupts != 0 || st.ReadyQueueDepth != 0 {
+	if st.SuspendStack != 0 || st.PendingInterrupts != 0 || st.ReadyQueueDepth != 0 {
 		t.Fatalf("排空后状态非空：%+v", st)
 	}
 	if st.Suspended == 0 || st.Resumed == 0 {