objects/uts: pin the sync-wait ordering with process_pending_events()

[sacOO7]

• Related to Objects: specify get() sync-wait failure (RTO23c1), malformed sync serial handling (RTO5a6) and related clauses, with UTS unit cases #514

Problem

The five sync-wait pseudocode blocks in uts/objects/unit/realtime_object.md (RTO23c1 ×3, RTO20e1 ×2) share a shape that is misleading for async SDKs: start an operation, ASSERT <future> IS NOT complete, then inject a channel-state change. The negative assert reads as immediately assertable, but on an SDK that dispatches get()/increment() asynchronously it is vacuous — true even if the operation hasn't started — and the subsequent state injection then races the operation's own dispatch. Depending on which wins, the SDK correctly takes either the pre-wait path (RTO23e/RTL33: 90001 or re-attach) or the parked-waiter path (92008) the block asserts. Both outcomes are spec-conformant; the pseudocode simply never pins which one the test exercises.

This is not theoretical: it caused a real CI failure in ably/ably-java#1228 (expected: <92008> but was: <90001>, reproduced locally 1-in-6 runs). ably-js's mocks process synchronously, so the reference implementation never exercises the gap — the pseudocode had no corrective there.

What changes

The corpus already defines the exact tool: process_pending_events() (uts/README.md §Conventions; writing-derived-tests.md §"prove a negative" mandates a yield before negative assertions). This PR deploys it explicitly in the five blocks, between the operation call and the negative assert, with pointer comments — the same per-site style realtime_client.md and channel_detach.md already use. The two FAILED blocks additionally explain the 90001-vs-92008 mechanism so future ports understand why the drain is load-bearing.

Representative before/after (RTO23c1-FAILED block):

# before
get_future = channel.object.get()
ASSERT get_future IS NOT complete
# inject ERROR -> FAILED ...

# after
get_future = channel.object.get()
# Drain queued async work so get() has parked its RTO23c sync waiter (and the negative
# assert below is meaningful) before the channel-state injection — see process_pending_events()
# in uts/README.md; async SDKs otherwise race the injection against get()'s own dispatch,
# observing the RTO23e/RTL33c pre-wait 90001 instead of the parked-waiter 92008.
process_pending_events()
ASSERT get_future IS NOT complete
# inject ERROR -> FAILED ...

Notes

• Not related to uts: define normative fake-time semantics (ADVANCE_TIME guarantee, hard-gate vs advisory, authoring rule) #518: that PR governs timer-driven work vs ADVANCE_TIME (fake-time semantics); this is dispatch-queue ordering with no timers involved — deliberately kept separate.
• The derived-test fixes already landed in ably-java ([AIT-1142] fix(liveobjects): objects audit conformance; refactor(uts): shared test-infra module ably-java#1228, commit a821d4bd + follow-ups) using its rendering of this convention (a sequential-scope flush); this PR encodes the determinism at source so other async-SDK ports don't rediscover it.
• No behavioural spec points change — the RTO23e/RTO23c1 semantics and error codes are untouched; this is test-pseudocode sequencing only.

[maratal]

LGTM