fix(回路): 人类经 /me/mail/send 插话也要解锁 —— 端到端实测抓到的缺口

上一提交（4d8165f）的 403 文案写着「若要立刻恢复，请由人类在会话里插一句话」，
但**那句话是假的**。

## 实测证据

拿真实用户登录态经 `POST /api/v1/me/mail/send` 在被锁会话里插话：

    HTTP 200  {"mail_id":"68eda0c3-…"}    ← 人类的信进去了（这是对的）
    session_agent_locks 锁行数: 1          ← ★ 锁还在

`MeSendMail` 有自己的 resolve + CreateMail，**根本不经过 Agent 侧那道闸**
（main.go 里 UserAuth 组下单独注册）。所以解锁只写在 `SendMail` 里是不够的：
人类插了话，锁仍要等满 2 小时。

## 为什么单测没抓到

`TestHumanPostClearsCooldownImmediately` 走的是 Agent 侧 handler，
证明了「解锁逻辑本身对」，却没证明「人类实际会走的那条路也解锁」。
判据钉的是 A 路径、生产走的是 B 路径 —— 这个形状本仓已遇到三次
（opencode 的 withScope、homeagent 的 InjectInputSync、这次）。

## 修法

把解锁放在 `SetSessionOwner` 旁边 —— 那是「人类参与这条会话」的权威落点，
比在每个调用点各写一遍可靠（漏一处就又是一句假承诺）。
解锁失败只记日志不阻断：人的来信优先入库，代价只是那把锁到期自消（保守方向）。

判据：新增 `TestHumanSendPathAlsoClearsCooldown`，走真实 `middleware.UserAuth`
+ 真实 user_sessions 行。变异（撤掉解锁）后该格变红。

踩到的两个测试夹具坑（都记在判据注释里）：
- 直接调 handler 会 401 —— 生产上这条路由在 UserAuth 中间件后面
- UserAuth → SessionToken 读 config.C.CookieName，而测试里 config.C 是 nil ⇒ panic

server/internal/handler/me.go

@@ -2,6 +2,7 @@ package handler
 
 import (
 	"errors"
+	"log"
 	"net/http"
 	"time"
 
@@ -122,6 +123,23 @@ func MeSendMail(w http.ResponseWriter, r *http.Request) {
 	// 人类发起的会话归属于该用户
 	_ = repo.SetSessionOwner(r.Context(), sessionID, user.ID)
 
+	// ★ 2026-10-01：人类在**这条路径**上插话也要立刻解除 Agent 回路冷静期。
+	//
+	// 我第一版只把解锁写在 Agent 侧 `SendMail` 里，而**人类根本不走那条路**
+	// —— 端到端实测：WebUI 用户经 `/me/mail/send` 插话返回 200（人类的信
+	// 本来就不该被回路闸拦，这是对的），可 `session_agent_locks` 那行**还在**。
+	//
+	// 于是错误文案里那句「若要立刻恢复，请由人类在会话里插一句话」是**假的**：
+	// 人类插了话，锁却要等满 2 小时。而这条文案正是我自己在 403 里写的。
+	//
+	// 放在 SetSessionOwner 旁边：那是「人类参与这条会话」的权威落点，
+	// 比在每个调用点各写一遍解锁可靠（漏一处就是一句假承诺）。
+	if _, err := repo.SessionLockTouch(r.Context(), sessionID); err != nil {
+		// 解锁失败不该拦下人类的邮件 —— 人的来信优先入库。
+		// 代价只是那把锁要到期才消（保守方向，不放宽任何闸）。
+		log.Printf("[agent-lock] 人类插话后解锁失败（锁将到期自消）: %v", err)
+	}
+
 	// 新建会话时定往返预算。只在新建时设：续谈已有会话若也接受这个字段，
 	// 每封新信都会悄悄改掉对方正在遵守的预算，人却不一定意识到自己改了。
 	//