docs(tasks): fold two mobile blockers into the reading-load round, brief touch targets and breakpoints

2026-09-15 的 UI 走查（web + 移动端）结果落盘。

并入 TASK-chat-reading-load：折叠层里的四列表在窄屏没有重排规则
（767 的卡片化只认三列，width:100% 又让 overflow-x 永不触发），它是
折叠能不能落地的前置；全局 input/select 是 14px，iOS 聚焦会把整页放大，
命中整条注册与资料录入漏斗。

新单 TASK-mobile-touch-and-breakpoints（BUG-695～697）：消息操作按钮
命中区 27×34 且相邻只隔 1px；CSS 平板上限 900px 与 sidebar-state.ts 的
1024 不一致，901–1023 是混合态；报告域 720/760/860 三刀互不对齐，
761–860 目录已塌、正文还是桌面。含断点白名单契约测试作为防复发。

另加 docs/testing/ios-keyboard-composer-20260915.md：html/body overflow
hidden + 100dvh 外壳 + sticky 输入框 + interactiveWidget 只有 Android 认，
是键盘遮挡的风险形状，但代码断不了真假，交真机确认后再决定是否立单。

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0155nFCgCHtoA7jhSDGmZmMu

docs/testing/ios-keyboard-composer-20260915.md

@@ -0,0 +1,55 @@
+# 真机清单 · iOS 键盘是否遮挡输入框（2026-09-15）
+
+**为什么需要人来测**：这一项无法从代码断定，也没有自动化替代。会话环境没有 iPhone、没有 Chrome、没有登录态。走查只能确认「风险形状成立」，不能确认「真的坏」。结论出来之前**不立修复单**。
+
+## 代码侧已确认的事实
+
+| 事实 | 位置 |
+| --- | --- |
+| 页面自身不可滚动 | `frontend/src/app/globals.css` → `html, body { width: 100%; height: 100%; overflow: hidden; }` |
+| 应用外壳锁死视口高度 | `.group\/sidebar-provider[data-viewport] { height: 100dvh; overflow: hidden; }` |
+| 输入框是滚动区外的粘性行 | `.composer-wrap { position: sticky; bottom: 0; }`；`.chat-panel` 用 `grid-template-rows` 把它排成独立一行 |
+| 只声明了 Android 认的键盘策略 | `frontend/src/app/layout.tsx` → `viewport.interactiveWidget = "resizes-content"`。**iOS Safari 不支持这个属性，会忽略** |
+| 没有任何 `visualViewport` 监听 | `grep -rn "visualViewport" frontend/src` = 0 命中 |
+
+这是「app shell + 锁定高度 + 粘性输入框」的典型形状。iOS 在键盘弹出时不缩小布局视口，只缩小可视视口；系统自带的 scroll-into-view 兜底在 `overflow: hidden` 的外壳里没有可滚的东西。**但 iOS 也可能自行平移可视视口把输入框顶上来**，所以必须实测。
+
+## 怎么测
+
+设备：iPhone。两个浏览器各测一遍——**Safari** 和**微信内置浏览器**（后者用的是 WKWebView，行为可能不同，而且很可能是真实用户的主要入口）。
+
+地址：`https://staging.jyotisha.chat`
+
+### A. 聊天输入框
+
+1. 登录，进入任意一个已有会话（不要用空首页，空首页的布局不同）。
+2. 点一下底部输入框，等键盘完全弹出。
+3. **看**：输入框整条是否还完整可见？发送按钮是否露在键盘上方？
+4. 连打三行以上文字，让输入框自己长高（它 `max-height: 128px`）。**看**：长高之后是否被键盘吃掉？
+5. 输入过程中，上方最后一条消息是否还看得见？还是被顶没了？
+6. 收起键盘。**看**：页面有没有留下一块空白，或者整体位置偏了没还原。
+
+### B. 长会话里的输入框
+
+1. 找一个消息很多、需要滚动的会话，滚到中间位置（不在底部）。
+2. 点输入框。**看**：弹键盘时页面有没有突然跳到别处。
+
+### C. 登录页与资料录入
+
+1. 退出登录，在 `/login` 点邮箱输入框。**看**：键盘弹出后输入框和「获取验证码」按钮是否都还可见。
+2. 新账号走一遍姓名 → 出生日期 → 出生时间 → 出生地搜索。出生地搜索会弹下拉列表，**重点看**：下拉列表是否被键盘压住、能不能点到。
+
+### D. 横屏
+
+把手机横过来重复 A.2。横屏时键盘占比更大，最容易暴露。
+
+## 怎么回报
+
+每一条写「正常 / 有问题 + 一句现象 + 截图」。截图请**不要**带真实姓名、出生资料或会话内容——用一个测试账号，或者截图后把这些涂掉。
+
+- 如果 A–D 全部正常：这一项关闭，记进本文件末尾，不开修复单。
+- 如果任何一条有问题：把现象贴回来，我据此出修复单。预判的修法是引入 `visualViewport` 监听把键盘高度写进一个 CSS 变量，由 `.composer-wrap` 消费；但具体怎么改要看实际是哪一种坏法。
+
+## 结论
+
+> 待填。测完把结论写在这里（日期 + 设备 + 浏览器 + 逐条结果），不要另开文件。