docs(tasks): 校正标题修补迁移的进度记录与 Bug 历史回填

- PROGRESS-rectification-title-repair-migration-20260916.md：前提复核、
  逐字一致的复核命令、幂等两层的说明、基线比对与环境缺口。
- BUG_HISTORY：BUG-699 / BUG-704 的「修复」补记改由迁移承担，「验证」
  的欠账改成待产品在 staging 应用后从 NOTICE 回填。不新增编号。
- BLOCKED.md：BLK-002 无 Docker / 无本地 PostgreSQL，test:db 未跑、
  db:migrate:check 缺 SCHEMA_DATABASE_URL，附已实跑的替代证据。
- deploy/README.md：一次性数据修补走同一个 Migrate Staging Database
  按钮，行数看日志里的 notice 行。
- docs/tasks/README.md：该单改记待验收。

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

deploy/README.md

@@ -214,6 +214,8 @@ curl -fsS https://staging.jyotisha.chat/api/health
 
 The normal application deployment workflow never runs database migrations. Apply migrations to the private staging PostgreSQL cluster first, verify them, and only then deploy application code that depends on them.
 
+One-off data repairs go through the same `Migrate Staging Database` button, not through ad-hoc scripts on the host: ship the repair as an ordinary migration under `frontend/supabase/migrations/` so the migrator applies it exactly once, and have it report how many rows it touched with `RAISE NOTICE`. `scripts/db-migrate.mjs` forwards notices, so those counts appear in the migration run log as `notice <message>` lines — that log is where you read the result. Write such repairs to be idempotent anyway (their `where` must stop matching rows they already fixed), so a manual re-run cannot double-apply. `frontend/supabase/migrations/20260916020000_rectification_session_title_repair.sql` is the worked example.
+
 ## Staging PostgreSQL operations
 
 This section is the server-side runbook for the disposable staging PostgreSQL volume. It does not replace the production instructions above.