Stabilize memory Phase 2 input ordering (#19967)

## Why

Phase 2 still needs to choose the most relevant stage-1 memory outputs
by usage and recency, but exposing that ranking as the rendered
`raw_memories.md` order creates unnecessary large diff. Usage-count or
timestamp changes can reshuffle otherwise unchanged memories, making the
workspace diff noisy and giving the consolidation prompt a misleading
recency signal from file position.
This fix will reduce token consumption

## What Changed

- Keep the existing top-N Phase 2 selection ranking by `usage_count`,
`last_usage`, `source_updated_at`, and `thread_id`.
- Return the selected rows in stable ascending `thread_id` order before
syncing Phase 2 filesystem inputs.
- Update the memory README, raw memories header, and consolidation
prompt so they describe the stable order and tell the prompt to use
metadata and workspace diffs instead of file order as the recency
signal.
- Adjust the memory runtime tests to use deterministic thread IDs and
assert the stable return order separately from the ranked selection
semantics.

## Test Coverage

- Existing memory runtime tests in
`codex-rs/state/src/runtime/memories.rs` now cover the stable returned
ordering for Phase 2 inputs.

---------

Co-authored-by: Codex <noreply@openai.com>

codex-rs/memories/README.md

@@ -94,7 +94,7 @@ What it does:
     `last_usage` / `generated_at`
 - computes a completion watermark from the claimed watermark + newest input timestamps
 - syncs local memory artifacts under the memories root:
-  - `raw_memories.md` (merged raw memories, latest first)
+  - `raw_memories.md` (merged raw memories, stable ascending thread-id order)
   - `rollout_summaries/` (one summary file per selected rollout)
 - keeps the memories root itself as a git-baseline directory, initialized under
   `~/.codex/memories/.git` by `codex-git-utils`
@@ -127,9 +127,10 @@ Selection and workspace-diff behavior:
 - Phase 1 upserts preserve the previous `selected_for_phase2` baseline until
   the next successful Phase 2 run rewrites it
 - Phase 2 loads only the current top-N selected stage-1 inputs, syncs
-  `rollout_summaries/` and `raw_memories.md` directly to that selection, then
-  lets the git-style workspace diff surface additions, modifications, and
-  deletions against the previous successful memory baseline
+  `rollout_summaries/` directly to that selection, renders `raw_memories.md`
+  in stable ascending thread-id order to avoid usage-rank churn, then lets the
+  git-style workspace diff surface additions, modifications, and deletions
+  against the previous successful memory baseline
 - when the selected input set is empty, stale `rollout_summaries/` files are
   removed and `raw_memories.md` is rewritten to the empty-input placeholder;
   consolidated outputs such as `MEMORY.md`, `memory_summary.md`, and `skills/`

codex-rs/memories/write/src/storage.rs

@@ -54,7 +54,7 @@ async fn rebuild_raw_memories_file(
         return tokio::fs::write(raw_memories_file(root), body).await;
     }
 
-    body.push_str("Merged stage-1 raw memories (latest first):\n\n");
+    body.push_str("Merged stage-1 raw memories (stable ascending thread-id order):\n\n");
     for memory in retained {
         writeln!(body, "## Thread `{}`", memory.thread_id).map_err(raw_memories_format_error)?;
         writeln!(

codex-rs/memories/write/templates/memories/consolidation.md

@@ -120,11 +120,12 @@ Primary inputs (always read these, if exists):
 Under `{{ memory_root }}/`:
 
 - `raw_memories.md`
-  - mechanical merge of `raw_memories` from Phase 1; ordered latest-first.
-  - Use this recency ordering as a major heuristic when choosing what to promote, expand, or deprecate.
-  - Default scan order: top-to-bottom. In INCREMENTAL UPDATE mode, bias attention toward the newest
-    portion first, then expand to older entries with enough coverage to avoid missing important older
-    context.
+  - mechanical merge of selected `raw_memories` from Phase 1; ordered by stable ascending thread id.
+  - Do not treat file order as recency or importance; use `updated_at`, workspace diff context,
+    and rollout content when choosing what to promote, expand, or deprecate.
+  - Default scan order: top-to-bottom. In INCREMENTAL UPDATE mode, use the workspace diff to find
+    changed entries first, then expand to unchanged entries with enough coverage to avoid missing
+    important older context.
   - source of rollout-level metadata needed for MEMORY.md `### rollout_summary_files`
     annotations;
     you should be able to find `cwd`, `rollout_path`, and `updated_at` there.