服务器长跑不再堆积取消监听，数据库少走几趟。

报告工人的等待到点就摘掉取消监听。本地数据库缓存表结构，并把设置身份合成一条语句，对照通过后默认打开，写成 off 仍走原来的语句。交付、重算和限流的内存表会过期。登录读缓存默认关闭，要开再设 IDENTITY_SESSION_COOKIE_CACHE=on。

自测：tsc 通过，lint 0 error，点名测试 134 通过，test:db 开关关和开都只有已知的 13 条失败，往返 49 降到 32。

Co-Authored-By: Grok (agent loop)

docs/BUG_HISTORY.md

@@ -17795,3 +17795,63 @@
 - 复发自：无。
 - 修复版本：未修复。
 
+## BUG-1326 | 个人报告工人空转时，取消监听一直留在进程上
+
+- 状态：resolved（代码+回归测试），生产内存曲线待部署后观察
+- 首次发现 / 最近更新：2026-10-13 / 2026-10-14
+- 来源：issue #58。任务书 T1。
+- 现象：报告工人长时间没有活干时，进程内存逐日上涨。取消这次工人时，之前每一次等待都还挂着一个取消监听。
+- 触发条件：工人循环用进程级取消信号，两次领任务之间按间隔等待。等待到点之后监听不摘。
+- 根因：等待用了「只触发一次」的取消监听。这个选项只在真的取消时摘掉监听。计时器自己到点时，监听还留在信号上。信号活得和进程一样长，监听就一直积着。
+- 修复：计时器到点时先摘掉监听再结束等待；真的取消时清掉计时器并结束等待。已经取消的信号仍立刻返回。计时器仍不挡住进程退出。引导打分里同一写法的等待也改成到点摘监听。
+- 验证：`frontend/tests/personal-report-worker-sleep-listener.test.ts` 4 通过。空转和抛错各 200 次后，取消前监听数是 0，取消后循环马上结束。修之前的同形等待在第 200 次时留下 199 个监听（断言 `199 !== 0`）。
+- 防复发：上述测试锁住「200 次之后监听数为 0」。
+- 相关记录：BUG-1328。
+- 复发自：无。
+- 修复版本：分支 `codex/node-runtime-resources-20261013`，尚未合入 staging。
+
+## BUG-1327 | 本地数据库每一问都重复查表结构和设置身份
+
+- 状态：resolved（代码+回归测试）。2026-10-14 对照通过后，两个开关默认打开。
+- 首次发现 / 最近更新：2026-10-13 / 2026-10-14
+- 来源：issue #58。任务书 T2。
+- 现象：同一次页面操作里，本地数据库要来回很多趟。表有哪些列、主键是什么、函数怎么调用，每次都现查。设置身份也要单独走一趟。
+- 触发条件：网页通过本地 Postgres 适配层读写真业务表。
+- 根因：元数据没有进程内缓存。设置角色和两条身份参数各是一条语句。事务的开始和提交仍各走一趟，这是故意留下的。
+- 修复：`JYOTISHA_PG_METADATA_CACHE` 缓存列类型、主键和函数签名，300 秒过期；缓存键带连接串，列和函数再带角色。不缓存空结果，也不缓存「函数不存在」。业务语句报列、表、函数或类型不匹配时，清掉该连接串的全部元数据并照旧返回错误，不自动重试。关掉某个连接或全部连接时，对应元数据一起清掉。`JYOTISHA_PG_MERGED_SESSION_SETUP` 把设置角色和两条身份合成一条参数化语句。角色仍只允许既有的两个业务角色。开始和提交不并进这条语句。两个开关都写成 `off` 时，语句顺序与改前一致。未设置或 `on` 为打开。只读且没有身份时省掉事务的做法已否决：那会把角色留在连接上，还回池子后可能给下一个请求。
+- 验证：不连数据库的往返单测锁住关闭时 6 条、打开且命中缓存时 4 条。真库测试确认事务内身份生效，连接归还后再借出时身份已空。对照脚本第二次（带三组原始数）整段往返 49 降到 32，耗时中位数 75.84 毫秒降到 36.48 毫秒，返回内容逐字节一致。第一次同样是 49 降到 32。`npm run test:db` 两轮都是 81 项、通过 68、失败 13、取消 0。失败名称与 Windows 已知清单逐条相同，没有多出来的。
+- 防复发：往返单测锁住关闭时的语句顺序，以及角色、参数名、报错、过期和关闭连接都会让缓存失效。
+- 相关记录：BUG-166、BUG-578、BUG-596、BUG-926。
+- 复发自：无。
+- 修复版本：分支 `codex/node-runtime-resources-20261013`，尚未合入 staging。
+
+## BUG-1328 | 三张只进不出的内存表会随运行变大
+
+- 状态：resolved
+- 首次发现 / 最近更新：2026-10-13 / 2026-10-14
+- 来源：issue #58。任务书 T3。
+- 现象：校正交付去重、重算尝试和请求限流各有一张进程内的表。旧条目读的时候已经不算数，却不删除，进程活得越久表越大。
+- 触发条件：长时间有人做校正或调用限流接口。
+- 根因：写入只增加，没有过期清理，也没有条数上限。
+- 修复：交付记录超过 60 秒就删，最多留 1 万条。重算记录改存时间，超过 6 小时就删，最多留 5 千条。限流按本进程见过的最大窗口定期删掉已经出窗的键；1 小时窗口的键不会在 61 秒时被删。限流的对外类型不变，调用方仍可传入自己的表。
+- 验证：交付、重算、限流的新测试通过。窗口内的允许或拒绝与原来的断言一致，没有改旧断言。同一道校正题在 6 小时内仍不会重算第二次；超过 6 小时或被挤出后可能再算一次，这比「进程一重启就可能再算」更收敛。
+- 防复发：硬上限和过期都有测试。1 小时窗口的键在短窗口清理后必须还在。
+- 相关记录：BUG-1326。
+- 复发自：无。
+- 修复版本：分支 `codex/node-runtime-resources-20261013`，尚未合入 staging。
+
+## BUG-1346 | 每次带登录的请求都重新读一次会话
+
+- 状态：resolved（代码+回归测试）。开关默认关闭：查库次数已下降，真实身份库的耗时对照还没做，未达到默认打开的门槛。
+- 首次发现 / 最近更新：2026-10-14 / 2026-10-14
+- 来源：issue #58。产品负责人 2026-10-14 决定可以开。任务书 T6。
+- 现象：每个已登录请求都到身份库读一次会话。
+- 触发条件：用户端 Better Auth 配置没有会话读缓存。后台没有另一份登录配置。
+- 根因：用户端会话配置未启用 `cookieCache`。
+- 修复：只有环境变量 `IDENTITY_SESSION_COOKIE_CACHE` 精确等于 `on` 时，用户端会话才缓存 300 秒。未设置或其它值与现在一样，每次读库。改密码、注销账户、以及全部后台入口每次都跳过缓存。改邮箱、两步验证和后台插件自带的敏感入口本来就会重新读库，这次没有改它们。咨询里的注销检查和后台的封禁检查仍每次查库。会话能活多久、改密码后是否作废、Cookie 的安全属性、表结构都没改。代价：缓存打开后，一台设备改了密码，其它设备上的旧登录最多还能再浏览 300 秒，这段时间做不了改密码和注销。
+- 验证：`frontend/tests/identity-session-cookie-cache.test.ts` 4 通过。缓存打开时连续 3 次普通读取只查会话 1 次，敏感读取每次都查；缓存关闭时 3 次都查。会话被清掉后，敏感读取立即无效，普通读取在 300 秒内仍有效，超过后无效。
+- 防复发：上述测试锁住开关关闭时不出现缓存配置，以及 300 秒后普通读取失效。
+- 相关记录：BUG-1327。
+- 复发自：无。
+- 修复版本：分支 `codex/node-runtime-resources-20261013`，尚未合入 staging。
+