回归上游的两阶段拆法

另外原分支基于 origin/xisheng，还带了 4 个与附件模型无关的 v0.0.2 release-note commit。已用 git rebase --onto origin/develop origin/xisheng <branch> 只重放 spec commit，甩掉那 4 个，并把 tracking 指向 origin/develop。分支与 worktree 原地保留，工作没丢。

LinkAttachmentsToIssue 回归上游三条件形态 —— 在当前基线上就是删掉两行：

UPDATE attachment
SET issue_id = $1
WHERE workspace_id = $2
  AND issue_id IS NULL
-  AND uploader_type = sqlc.arg(uploader_type)   ← 删
-  AND uploader_id   = sqlc.arg(uploader_id)     ← 删
  AND id = ANY($3::uuid[]);

原草稿同一条 requirement 里既说「不得在线删除对象」又说「容器删除连带删对象」，自相矛盾。已拆开：

• 禁止：任何基于时间的自动删除路径。附件不因「未绑定」或「超过时长」被后台回收。
• 保留：删除 issue / comment / 显式删附件时，连带删除对象存储文件（基线行为）。
• 明确：删除 Work / chat 会话时只级联数据库行、不删对象，产生的 blob 是接受的永久 orphan —— 写进 spec，不留未定义。

阶段一 · 只改代码

1. 先停 sweeper（最高优先级，可单独先发）：main.go 移除启动，删 attachment_sweeper.go 与其测试，删查询 DeleteExpiredStagedAttachments。
2. 停止读写 expires_at：UploadFile 不再写入；各 Link / Replace 查询不再清空；移除 StagedAttachmentTTL 与 staged_ttl_secs。
3. 删除附件级读授权，读取调用点改为 workspace 成员判定；保留 attachmentRequiresCreatorScope 供 URL 策略使用。
4. 绑定回归上游（删两行）。
5. 新增失败可观测性：CLI warnUnboundAttachmentIDs + 服务端 dropped-id slog.Warn + 单测。

阶段二 · 迁移

DROP TRIGGER IF EXISTS trg_agent_promote_avatar_attachment ON agent;
DROP TRIGGER IF EXISTS trg_user_promote_avatar_attachment ON "user";
DROP TRIGGER IF EXISTS trg_workspace_promote_avatar_attachment ON workspace;
DROP TRIGGER IF EXISTS trg_squad_promote_avatar_attachment ON squad;
DROP FUNCTION IF EXISTS promote_avatar_attachment();
DROP INDEX IF EXISTS idx_attachment_staged_expiry;
ALTER TABLE attachment DROP COLUMN IF EXISTS expires_at;

down.sql 重建列（全 NULL）、索引、函数与 4 触发器。列内容不可逆恢复 —— 但阶段一后已无语义消费者。迁移号按 develop 当前最大值 +1 确定，不预先写死。

1. expires_at IS NOT NULL 的行数，及其中三外键全 NULL 的行数 —— 现行判据下「随时可能被删」的集合。
2. 上述集合中 url 被任一 avatar_url 引用的行数 —— 曾经/仍处于误删风险的头像。
3. avatar_url 形如 /api/attachments/{uuid}/download 的 agent/user/workspace/squad 行数 —— 迁移 248 之后仍在产生的坏数据存量。
4. 上述 3 中对应 attachment 行已缺失的条数 —— 已发生且不可恢复的损失规模。

新增覆盖：

• agent 携带人类上传的 chat 附件 id 建单，绑定成功（MIA-284 回归）。
• 附件读取仅要求 workspace 成员；非成员 404。
• UploadFile 不写入 expires_at。
• Work 会话级门禁仍生效：非 creator 取会话 / 云盘 / task messages 全被拒 —— 这是决策 1 的前提，必须有测试锁住。
• 容器删除仍删对象（issue / comment / 显式删附件），而会话删除不删对象。
• CLI 未绑定告警的三种形态。

Work 会话云盘既有测试须全部保持通过。

下列都属于「持久引用与可渲染性」这一条轴，产品决策为与 MIA-279 合并处理，MIA-277 / MIA-278 已在 issue 树上挂到 MIA-279 之下：

• staged 附件 url / download_url / markdown_url 改写是否移除，以及按部署形态（CloudFront 签名 / 公开 CDN 无签名 / 本地存储）分别采用什么 URL 策略。
• 是否删除 fork 专用的 POST /api/avatar-upload、UploadAvatar、isAllowedAvatarContentType，让头像回到普通附件上传接口（上游本来就是这样）。
• 是否从上游移植 server/internal/handler/avatar.go 与 /api/avatars/{sig}/* 签名头像读取路由（MUL-5393 / #6024）。Rollica 当前没有该文件。
• GIF 头像支持（review P2）：删掉专用端点后格式白名单随之消失，问题自动解决。
• 图片 / Markdown 下载按钮无响应（MIA-279 本体）。