fix: serialize PropertyObservable / PropertyChangingObservable initial-emit with concurrent handlers

[dwcullop]

Fixes #38.

PropertyObservable<T>.Subscription attaches the source's PropertyChanged handler before reading and emitting the initial value, but the constructor's read-state-emit sequence is not synchronized with the handler it just attached. A mutation on a background thread that fires PropertyChanged between the attach and the constructor's state writes produces two emissions of the same value: the racing handler sees _hasValue == false, skips the distinct check, and emits; the constructor then re-emits the same value with no dedup. With distinctUntilChanged: true the downstream observer expects no two consecutive equal values; the race lets one through. A related variant lands when the mutation falls between the constructor's read and its emit, in which case the constructor delivers a stale value after the handler's fresher emit.

This serializes the constructor's initial-emit and the handler's body under a shared per-instance gate, extracted into an EmitCurrent helper called from both the constructor and OnPropertyChanged. Any racing handler runs either fully before or fully after the constructor's emit. The distinct check now also applies on the initial emit, so the case where a racing handler emits first under the original distinct-skipping branch (taken because _hasValue was still false) no longer produces a duplicate.

PropertyChangingObservable<T> receives the same EmitCurrent pattern for shape-consistency. The fire-PropertyChanging-then-write semantics on a normal INPC setter make the analogous out-of-order case naturally unreachable on that type (handler runs synchronously and completes its emit before the setter writes, so the main thread can only read the new value after the handler emit is already through the downstream observer), but the gate keeps the two subscription types consistent and guards atypical user implementations.

Tests

Two multi-threaded stress tests in PropertyObservableSubscribeRaceProbeTests, each 5_000 iterations of PropertyObservable<T> with distinctUntilChanged: true against a mutator thread writing the property 32 times.

Subscribe_ConcurrentMutationDuringInitialEmit_DoesNotEmitConsecutiveDuplicate asserts the dedup contract directly: no consecutive duplicate emission ever reaches the downstream observer. Without the fix it produces roughly 100-300 iterations with a consecutive duplicate per run on my machine; with the fix it produces zero.

Subscribe_AfterSettlement_LastObservedValueMatchesProperty asserts the end-to-end invariant that the subscriber's last observed value equals the property's final value once everything has settled. The mutator does a synthetic PropertyChanged re-fire after a synchronization barrier so the assertion measures the subscription's behaviour rather than the orthogonal INPC event-accessor visibility race (the mutator's PropertyChanged.Invoke can otherwise read a stale snapshot of the delegate that omits the just-attached handler). With the fix this test passes; the test does not by itself differentiate fixed from unfixed code (duplicate emissions don't change the final value), so it documents the invariant rather than acting as a regression probe.

The 481 pre-existing Observables tests continue to pass.