[BUG] - Era mismatch on tx submission reports the era where translation got stuck

**Internal/External**
Internal (IOG)

**Summary**

When you submit a transaction from an older era to a node that is running in a newer era, the node tries to translate the transaction forward, era by era. If the translation fails somewhere along the way, the transaction is rejected with `HardForkApplyTxErrWrongEra`, but the `EraMismatch` returned doesn't contain enough information to understand what happened:

- `otherEraName` seems to contain the era where the translation got stuck, not the era of the transaction that was submitted. For example, I submitted an Alonzo-era transaction to a Dijkstra-era node and the rejection contained `ledgerEraName = "Dijkstra"` and `otherEraName = "Conway"`. Conway is neither the era of the node nor the era of the transaction, and the submitted era is not included anywhere in the error, so clients have no way to present something sensible to the user. (`cardano-cli` renders it as: *"The node is running in the Dijkstra era, but the transaction is for the Conway era."*)
- The reason the translation failed is not included either. In this case, the actual cause was that `Dijkstra` no longer accepts certificates without deposits, but that information is dropped, so it cannot be discovered from the outside.

The issue seems to be with the `EraMismatch` produced by the hard-fork mempool ([`Mempool.hs#L451-L455`](https://github.com/IntersectMBO/ouroboros-consensus/blob/04a5353c8d9f4305ed636c9cdc054e4a731a37fd/ouroboros-consensus/src/ouroboros-consensus/Ouroboros/Consensus/HardFork/Combinator/Mempool.hs#L451-L455)).

**Steps to reproduce**

1. Run a network in the Dijkstra era (e.g. `TestDijkstraHardForkAtEpoch: 0` in the node config, protocol version 12 in genesis).
2. Build and sign a transaction in an older era that includes a legacy depositless stake registration certificate.
3. Submit it. The rejection reports the transaction as being for the Conway era.

**Expected behavior**

The rejection should carry the era the transaction was actually submitted in, and ideally also the reason the translation failed, so that clients can produce an accurate message, e.g.:

```
The node is running in the Dijkstra era. The transaction was submitted as an Alonzo-era
transaction; it could be translated up to Conway, but translation into Dijkstra failed:
Certificates without deposits are no longer supported.
```

Once the error carries this information, `cardano-cli` (and other clients) can be updated to give a better error message to the users.

**System info**

- OS: Linux x86_64
- Consensus version: observed on the `leios-prototype` fork @ `a2583031`; the relevant code is the same on `main` @ `04a5353c`

**Additional context**

The rejection itself seems correct (Dijkstra doesn't allow depositless certificates) — this issue is only about the information carried by the error.