fix(security): sanitize CheckpointStore seed_id to prevent path traversal

[shaun0927]

Summary

• Fixes security(persistence): CheckpointStore seed_id path traversal allows arbitrary file write/delete #397 — CheckpointStore._get_checkpoint_path() directly interpolated seed_id into filenames without sanitization, allowing crafted IDs like x/../../PWNED to read, write, or delete files outside the checkpoint directory.
• Adds _sanitize_seed_id() static method that strips null bytes, removes .. traversal sequences, replaces / and \ with underscores, limits length to 255 chars, and raises ValueError for empty results.
• Adds _validate_path_containment() that verifies the resolved checkpoint path stays within self._base_path.
• Both guards are applied in _get_checkpoint_path(), which is used by save(), load(), and all rollback operations.

Test plan

• Path traversal with forward slashes is sanitized (file stays in base dir)
• Path traversal with backslashes is sanitized
• No file is created outside the checkpoint directory
• Normal seed_ids continue to work (save + load roundtrip)
• Empty seed_id raises ValueError
• Null-byte-only seed_id raises ValueError
• ..-only seed_id raises ValueError
• Null bytes are stripped but remaining content preserved
• Seed IDs longer than 255 chars are truncated
• load() with traversal seed_id resolves consistently with save()
• All 34 existing + new tests pass
• ruff check passes clean

[ouroboros-agent]

Review — ouroboros-agent[bot]

Verdict: APPROVE

Reviewing commit 72485a7 for PR #413

Blocking Findings

No in-scope blocking findings remained after policy filtering.

Non-blocking Suggestions

#	File:Line	Category	Finding

Design Notes

The path-traversal goal is valid, but folding raw identifiers directly into sanitized filenames changes the storage key contract. This needs a collision-resistant mapping with an explicit filename-length budget, rather than lossy replacement plus truncation.

---

Reviewed by ouroboros-agent[bot] via Codex deep analysis

[ouroboros-agent]

Review — ouroboros-agent[bot]

Verdict: APPROVE

Reviewing commit 38b3aa4 for PR #413

Blocking Findings

No in-scope blocking findings remained after policy filtering.

Non-blocking Suggestions

#	File:Line	Category	Finding

Design Notes

The traversal hardening is directionally correct, but it was added at the filename layer without preserving a one-to-one mapping between logical seed IDs and on-disk keys. For persistence code, the key derivation has to remain collision-free or be explicitly rejected.

---

Reviewed by ouroboros-agent[bot] via Codex deep analysis

[shaun0927]

Labels: security persistence — Fixes #397

[Q00]

Requesting changes because the filename-length hardening is still incomplete.

_sanitize_seed_id() truncates the raw seed id to 255 characters, but _get_checkpoint_path() then wraps it in checkpoint_<seed>.json / .json.<level>. That still produces basenames longer than 255 bytes on common filesystems (len("checkpoint_") + 255 + len(".json") = 271), so long seed ids can still fail with ENAMETOOLONG on save/load.

Please cap the sanitized id to the remaining filename budget after the prefix/suffix, and add a regression test that actually writes a long-id checkpoint instead of only asserting on the generated path string.

[ouroboros-agent]

Review — ouroboros-agent[bot]

Verdict: APPROVE

Reviewing commit 17b5c70 for PR #413

Blocking Findings

No in-scope blocking findings remained after policy filtering.

Non-blocking Suggestions

#	File:Line	Category	Finding

Design Notes

The hardening is heading in the right direction, but it currently treats filename safety as a lossy string rewrite. For persistence keys, the safer shape is a reversible or collision-resistant mapping from raw seed_id to filename, with byte-based length enforcement rather than character-count enforcement.

---

Reviewed by ouroboros-agent[bot] via Codex deep analysis