[M154] SmartCard: Fix browser crash on consecutive transactions

When a SmartCardTransaction ends, its Mojo receiver in the browser
process was previously not removed, and the receiver disconnect
handler did not track transaction identity (only checking whether any
transaction was active on the handle).

Consequently, when Blink's garbage collection swept the previous
transaction's remote during a subsequent active transaction, the
disconnect handler prematurely cleared the active transaction state.
Ending the subsequent transaction then failed a CHECK_EQ in
EndTransactionInternal and crashed the browser process.

This CL resolves the issue by:
1. Associating active transactions with their mojo::ReceiverId in
   ContextData and verifying receiver identity on disconnect.
2. Removing transaction receivers upon EndTransaction completion.
3. Replacing CHECK_EQ in EndTransactionInternal with graceful error
   handling (kNotTransacted).
4. Explicitly resetting the Mojo remote in Blink's
   SmartCardConnection::CleanupTransactionState().
5. Adding an end-to-end browser test replicating the race.

(cherry picked from commit 8836aaf7679e00984c1294f3518543fc3f613327)

Bug: 555104067
Fixed: 556185357
Change-Id: I831e88256a99e2c22526412ceec378f96a6a6964
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/8324627
Commit-Queue: Zgroza (Luke) Klimek <zgroza@chromium.org>
Reviewed-by: Andrew Rayskiy <greengrape@google.com>
Cr-Original-Commit-Position: refs/heads/main@{#1690525}
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/8353185
Bot-Commit: rubber-stamper@appspot.gserviceaccount.com <rubber-stamper@appspot.gserviceaccount.com>
Commit-Queue: rubber-stamper@appspot.gserviceaccount.com <rubber-stamper@appspot.gserviceaccount.com>
Auto-Submit: Zgroza (Luke) Klimek <zgroza@chromium.org>
Cr-Commit-Position: refs/branch-heads/8037@{#113}
Cr-Branched-From: e10b20e60f162e7ad88e4930833695a54f4e15fb-refs/heads/main@{#1689415}