-- 0028 的回滚：只撤结构（删列），**不改写任何一行的其它数据**。
--
-- 回滚的代价（如实登记）：`sensitive` 的标记值全部丢失 —— 所有行回到「非敏感」，
-- 于是受限车道（群聊 / 陌生人）会重新把主人的私事捞进候选池，即 2026-10-29 的
-- 泄漏面重新打开。这是**预期**的回滚代价，不是 bug：本列的值无法从其它列派生
-- （判据是内容白名单 + 提取器判断，见 up 文件），因此回滚必须显式承认它丢信息。
--
-- 回滚**不许**顺手把那些私事行改成别的形态（删行、改 scope、改 status）：
--   - 删行 / 改 scope 是一次 schema 回滚**改数据**，且不可逆（内容就没了）；
--   - 改 status 会把在册记忆藏起来，读侧闸看起来「干净」，但数据其实还在 ——
--     那正是本片要消灭的「靠不可见假装安全」。
-- 要恢复保护就重跑 up（列以默认 0 重建）或执行 memory 包的 BackfillSensitive
-- （幂等、可 dry-run，见 internal/runtime/memory/sensitive_backfill.go）。
--
-- SQLite 的 DROP COLUMN 要求该列不被索引/视图/触发器引用：本列没有索引（见 up），
-- 因此无需先删索引（0026 的 down 因为带索引才以 DROP INDEX 开头）。
ALTER TABLE memory_items DROP COLUMN sensitive;