Proposal: bump history_version when remove_first_item rewrites history

Summary

This is a proposal submitted as an issue because this repository restricts pull requests to collaborators.

ContextManager::remove_first_item() rewrites the history transcript (removes the oldest item and its call/output counterpart) but never bumps history_version, while the field is documented as "Bumped whenever history is rewritten, such as compaction or rollback". The fix keeps the "mutation bumps the version" invariant true for all mutation APIs.

Why it matters

history_version is a correctness signal: guardian/review_session.rs uses parent_history_version as a reuse key for review sessions. Today's only caller (compact.rs retry-trim) mutates a private clone_history() snapshot, so COW isolates the live history and the missing bump is currently harmless. But the pub(crate) API carries no such contract, and any future caller trimming the live history would silently invalidate review-session reuse.

Patch

One line, in codex-rs/core/src/context_manager/history.rs:

            normalize::remove_corresponding_for(items, &removed.item);
            self.world_state_baseline = None;
+           self.history_version = self.history_version.saturating_add(1);

Plus two unit tests (bump semantics + COW snapshot isolation) in history_tests.rs.

Verification

cargo test -p codex-core --lib remove_first_item                     # 6 passed (4 existing pairing + 2 new)
cargo test -p codex-core --lib context_manager::history::tests       # 72 passed, 0 failed

Full change is pushed on fork branch: runzhong123-max:fix/history-version-bump-on-remove-first-item (commit 5272921, +88/−0, two files).