The checkInFailed() method was using workspace.isTreeLocked() to determine
whether to call endRule(), but this is unreliable because:

1. If checkIn() throws an exception BEFORE calling beginRule() (e.g., tree
   already locked), then endRule() should NOT be called
2. If checkIn() throws an exception AFTER calling beginRule() (e.g.,
   lock.acquire() fails), then endRule() MUST be called to avoid orphaning
   the rule

The tree lock status at cleanup time cannot reliably distinguish between
these two cases because the tree may become locked (e.g., during resource
change notifications) between the checkIn() call and the cleanup.

The fix adds a new ThreadLocal flag 'beginRuleCalled' to explicitly track
whether beginRule() was called, ensuring that endRule() is only called when
needed, regardless of the current tree lock status.

This fixes the "endRule without matching beginRule" error that can occur
in concurrent scenarios where resources are being modified in one thread
while being read in another.

Addresses discussion eclipse-platform#2242

Co-authored-by: laeubi <[email protected]>

Created WorkManagerTest.testCheckInFailedWithTreeLockDoesNotOrphanRule() to
reliably reproduce the race condition fixed in WorkManager.checkInFailed().

The test uses reflection and latches to create the exact scenario:
1. beginRule() is called successfully
2. checkIn() then fails (simulated via ThreadLocal manipulation)
3. Workspace tree locks during cleanup (via resource change listener)
4. checkInFailed() is called for cleanup

Without the fix:
- checkInFailed() would see tree is locked and skip endRule()
- This orphans the rule
- Second endRule() call succeeds (proving first was skipped) - TEST FAILS

With the fix:
- checkInFailed() checks beginRuleCalled ThreadLocal
- Calls endRule() correctly regardless of tree lock status
- Second endRule() call fails with expected error - TEST PASSES

The test is deterministic and does not rely on timing or randomness.

Co-authored-by: laeubi <[email protected]>