Equal `seen_at` and `evicted_at` within one sync hides present tx

**Describe the bug**
A sync queries script histories independently but assigns every result the same start_time.

If unconfirmed T is already expected on two wallet scripts, this sequence is possible:

1. First query omits T, so BDK infers eviction.
2. T enters or re-enters the mempool.
3. Second query sees T.

The update contains equal-timestamp seen_ats and evicted_ats. Because ties count as evicted (last_evicted >= last_seen), BDK incorrectly hides T.

The shared timestamp loses this ordering. A brand-new payment is not in expected_txids, so a miss then a hit is only seen_ats and does not hit this bug.

The same dual-stamp (false eviction) also happens if T never left and one history is just incomplete.

**To Reproduce**

1. Start syncing two scripts that both expect unconfirmed transaction `T`.
2. Let the first query omit `T`.
3. Add or re-add `T` to the mempool before the second query.
4. Let the second query return `T`.
5. Apply the update.
6. Observe that `T.is_evicted()` is `true`, despite the latest observation seeing it.

**Expected behavior**
The later observation should determine the transaction’s state. In this sequence, `T` was seen after the inferred eviction, so it should not be marked evicted.

**Build environment**
- BDK tag/commit: `456f9b7bbf510eefdf3e7a164a5d6bc4cd668adb`

**Which backend(s) are relevant (if any)?**
- [x] Electrum
- [x] Esplora

**Is this blocking production use?**
- [x] No

**Additional context**
Independent queries may observe different mempool/index states. BDK assigns both results the same sync start timestamp.

Start by tracing the sync update path for the Electrum and Esplora backends, focusing on how the shared sync start_time is assigned and how seen_at and evicted_at are compared. Reproduce the two-script sequence from the issue, then verify that the later observation determines the transaction state and T is not marked evicted.

Written by the indexing model from the issue text.