fix(core): validate replay operation identity

[zhongkechen]

Summary

• validate checkpoint type, subtype, and name before operation-specific replay handling
• fail mismatches with NonDeterministicExecutionError instead of consuming another operation's checkpoint
• cover type, subtype, and name drift through unit and end-to-end regression tests

Testing

• 1,587 core non-e2e tests passed
• 46 core e2e tests passed
• hatch run dev-core:typecheck
• hatch fmt --check

Closes #692

[github-actions]

Codex AI review · Finding arf_v1_o3j43byu5wye3ohznhuk67z3bs

[P1] Allocate the operation ID atomically

_peek_next_operation_id() and _create_step_id() lock the counter separately. Two threads sharing a DurableContext can therefore both construct identifiers for step N; the second thread increments to N+1 but still checkpoints operation N, causing duplicate IDs and cross-operation checkpoint consumption. Atomically reserve the ID first, then make _replay_aware inspect that allocated ID. Add a barrier-based shared-context test.

[github-actions]

Codex AI review · Finding arf_v1_qvxigbpmdlmtzxjwsutttqe7or

[P1] Reject container checkpoints for virtual children

Virtualness is not part of OperationIdentifier. If a previously non-virtual run_in_child_context changes to ChildConfig(is_virtual=True), its existing successful CONTEXT checkpoint passes this validation and the method returns the cached result without executing the now-virtual body, so the changed inner hierarchy is never validated. When self.is_virtual, reject any existing container checkpoint before terminal handling, and add a non-virtual-to-virtual replay test.

[github-actions]

Codex AI review

Two replay-safety issues remain: shared contexts can allocate duplicate operation IDs, and virtual child contexts can consume checkpoints from non-virtual history.

Reviewed commit a2233e9a9a3d88aedb29fe9b7dcc775f3b056252. Workflow run