[Bug]: Tom processing history can checkpoint events that were never indexed

Bug Description

Tom candidate selection reads each session's current event count (openhands-tools/openhands/tools/tom_consult/executor.py:283-304) and extracts the payload sent to Tom (:313-332,374-380). After Tom succeeds, _save_processing_history() re-lists each mutable event directory to reconstruct counts (:397-416) and is given the broader candidate-ID list rather than only successfully extracted payloads.

If an event arrives after extraction but before that second listing, history records the newer count even though the event was never sent to Tom. The next run then treats it as already processed. Sessions whose extraction produced no payload can also be checkpointed.

Expected Behavior

The persisted checkpoint should describe exactly the snapshots successfully submitted to Tom; later events must remain detectable.

Actual Behavior

An independent, self-contained reproducer is posted in the issue comments. Save
it as /tmp/repro_4667.py, then run:

uv run python /tmp/repro_4667.py

On SDK commit bc5dfc50d, it exercises the real LocalFileStore, EventLog, executor, history file, and second index pass; only the external Tom call is a fixture, where a real event is appended during submission and prints:

indexed_event_count=1
actual_event_count=2
checkpoint_directory_entry_count=4
first_sessions_processed=1
second_sessions_processed=0

Suggested Implementation

Carry each candidate's pre-submission directory-entry count alongside its extracted payload. After a successful Tom call, persist that count only for sessions whose extraction produced a submitted payload, and perform no second event-directory read. This keeps the checkpoint in the same unit used by candidate selection while preserving the current history JSON shape.

Acceptance Criteria

• last_event_count equals the pre-submission directory count for the successfully extracted and submitted payload.
• An event appended during processing is detected on the next run.
• Sessions that fail extraction are not marked processed.
• A failed Tom call does not advance history.
• Existing history entries and JSON compatibility are preserved.

Version

Current main at 6d3881035. Existing issue search found no duplicate.

Start by saving the reproducer from the issue comments as /tmp/repro_4667.py and running it with uv run python /tmp/repro_4667.py. Read the candidate selection and _save_processing_history() paths in openhands-tools/openhands/tools/tom_consult/executor.py:283-304, 313-332, 374-380, and 397-416. Done means checkpoints use the pre-submission count only for successfully submitted payloads, preserve history JSON compatibility, and detect events added during processing on the next run.