Event set spent while queued is still processed as a stop #44

Follow-up from PR #41 (ResumeLedger).

A JDI event set can wait for the event dispatcher while it handles the sets before it. When a tool (jdwp_resume, jdwp_resume_thread, a step) resumes the set's thread in that time, the set's suspension is spent. Since PR #41, ResumeLedger detects this, and the dispatcher no longer resumes such a set. The set is still processed as if its thread were stopped:

• Breakpoint: the hit is still reported as a stop (BREAKPOINT entry, lastBreakpointThread, the jdwp_resume_until_event latch), although the thread runs. Inspecting it then fails with IncompatibleThreadStateException.
• Logpoint or condition: the expression is evaluated on a running thread. This fails and records a LOGPOINT_ERROR / CONDITION_ERROR entry that only reflects the race.

This is not new. It happened on main whenever the listener was busy, and in the old architecture too. The difference is that the server can now tell.

Proposal: when ResumeLedger.spent(claim) holds at dispatch start, still record the hit, but as a distinct entry (e.g. BREAKPOINT_SPENT). Do not publish it as the current stop and do not fire the latch. Skip evaluating logpoints and conditions, which would only fail.

Acceptance:

• A unit test queues a breakpoint set behind a blocked evaluation and resumes its thread through ResumeLedger. The hit is recorded, but lastBreakpointThread is unchanged and the latch is not fired.
• The same test with a logpoint records no LOGPOINT_ERROR.
• docs/event-pipeline.md §1 no longer lists this as not covered.