fix(storage): deterministic ID ordering in memory-mode ListProjectRefs

Memory CAS iterated memoryRefs map (random order) while PG path uses
ORDER BY id ASC; asset dedup-hint 'first reference unflagged' logic
depends on stable order. Flaky TestUploadProjectAsset_DedupHint
reproduced 2/20 rounds before fix, green 30/30 after.

.doc/ops/short-term/2026-09-25-server-image-field-closeout.md

@@ -14,6 +14,7 @@ base_dev_sha: "44161d2ad2d7aada3e9ff88127b52148543278e5"
 write_scope:
   - internal/server/
   - internal/app/
+  - internal/storage/
   - deploy/postgres/goose/
   - .doc/ops/short-term/
   - .doc/test-reports/
@@ -51,6 +52,7 @@ remote_sync: not_requested
 4. **附带修复（既有债务撞车）**：
    - `Shutdown` 与 4 个后台循环（sweeper/publisher/reminder/wsGC）对 stop 通道的 DATA RACE——dev 基线 `44161d2a` 复测同样失败（`chat_turn_sweeper.go:21` vs `server.go:471`）。新增 `backgroundLoop`（mutex + `sync.Once` 通道），通道只在 loop goroutine 内创建持有，`Shutdown` 经 `stop()` 通知。
    - **goose 00071 版本号冲突**：`1da17a28` dialogue 合并同时带入两个 `00071_*`（maintenance-windows、context-conflict-adjudications），goose sort panic 阻塞全仓 `go test`。dev 库（`agent_system_dev@5433`）已应用至 00070、两个 00071 均未应用 → `context-conflict-adjudications.sql` 重编号 `00072`，零数据迁移。
+   - **`ListProjectRefs` 内存模式排序缺失**：map 迭代顺序随机令「同 SHA 首条引用不标 dedup」判定不稳定（`TestUploadProjectAsset_DedupHint` 20 轮 2 失败复现）。内存路径补 `sort.Slice(by ID)` 与 PG `ORDER BY id ASC` 对齐，修复后 30 连跑全绿。
 5. `task_finalize_test.go` 改用 `newMinimalRuntime`（仅测试所需字段的 `app.Runtime`）。
 
 ## 非目标

internal/storage/cas_assets.go

@@ -5,6 +5,7 @@ import (
 	"errors"
 	"fmt"
 	"io"
+	"sort"
 )
 
 // ListProjectRefs 列出项目下全部 CAS 文件引用（智能体任务上下文资产池）。
@@ -43,6 +44,9 @@ func (c *CAS) ListProjectRefs(ctx context.Context, projectID int64) ([]*FileRefe
 			refs = append(refs, &cpy)
 		}
 	}
+	// 与 PG 路径 ORDER BY id ASC 对齐：map 迭代顺序随机，
+	// 会令 handler 的「首条引用不标 dedup」判定不稳定（偶发测试失败）。
+	sort.Slice(refs, func(i, j int) bool { return refs[i].ID < refs[j].ID })
 	return refs, nil
 }