fix: keep a resolved lock when a later presence message lists it as pending

[RaphaelFakhri]

Related to #338

Description

When a member acquires several locks concurrently, for example with Promise.all(), acquire() publishes one presence update per lock. Each update carries every lock request the member has so far, and none of them are resolved yet, so the later messages list the earlier locks as pending again.

Locks.processPresenceMessage resolves a pending request to locked (or unlocked) when it first sees it. When the next message arrived, the same request was still listed as pending, so the stored lock moved back from locked to pending. The update event reported pending, and no later event reported locked again. Depending on message order, only some of the locks stayed locked, which matches the inconsistent results in #338.

This change ignores a pending entry when the stored request for the same lock has the same timestamp and is already resolved.

Testing

• Adds a Locks test that processes two presence messages in the order acquire() publishes them: [a pending], then [a pending, b pending]. It expects both locks to be locked.
• The test fails without the change (expected 'pending' to be 'locked', 1 failed of 21) and passes with it (21 passed).
• The full unit suite passes (119 tests). prettier --check and eslint are clean.

Run with:

npx vitest run src/Locks.test.ts

[ttypic]

LGTM, thanks for contributing