AskaEth
6d158ca9bd
r2 复审指出 `loadIncrement` 的第三档（`!hasMore` ⇒ `complete = true`）是空页档同一个
洞的另一个出口：它只看「本页满不满」，不看整个追尾里有没有拿过满页。
反例（页宽 2、`after=0`、积压 m1@500 / m2@500 / m3@500 / m4@600）：第一页给
[m1,m2]（满页，服务端 LIMIT 恰好把 500 那一毫秒劈开），第二页 `after=500` 只给
[m4@600]、不满页 ⇒ 旧代码报 `complete = true`，而 m3@500 既不 `> 500`、永远拿不到，
也不会触发回落整表 —— 未读红点被做小，正是这条增量路径最不能出的错。
改法：第三档改为 `complete = !chasedFullPage`，不变式收紧为
complete = true 当且仅当整个追尾从未拿过满页。
理由写在 KDoc 里：只有服务端的 LIMIT 在某一毫秒中间切过一刀才会留尾巴，客户端看不见
那一刀落在哪儿，只知道自己拿过满页就等于发生过一次切点 —— 此后无论下一页是空页还是
不满页，都说不出「追到了尾巴」。四档表（第一页空 / 第一页不满 / 满页后空 / 满页后不满 /
翻满 maxPages）与代价段一并重写。
代价（复审已认可）：积压 ≥ 页宽（默认 50 条）一律回落整表，与「翻满 MAX_INCREMENT_PAGES
⇒ 回落」同类，也正合那句「积压多到增量不再便宜」；主路径（几条新消息、第一页就不满）
不受影响。
- `MessageRepository.loadIncrement`：标志位 + 第三档出口，KDoc 不变式与四档表重写；
- `MessageRepository.loadAfter`：KDoc 的告警从「满页之后的空页」改为「满页之后的一页
（空页、不满页都一样）」；
- `SessionsViewModel.flushPendingIncrements`：回落理由 2 同步为「整个追尾里拿过整页」；
- 新增反例测试 `a short page after a full page is not proof of a clean tail either`。
验证：`./gradlew testDebugUnitTest assembleDebug` BUILD SUCCESSFUL；135 个套件
1692 条测试全绿（上一轮 1691，+1 即上述反例），0 failures / 0 errors / 0 skipped。