/mining-status can overcount solved transactions compared to Prometheus and Explorer

## Problem

The transaction counters exposed by `/mining-status` do not appear to be reliable.

Observed behavior shows `/mining-status` overcounting solved transactions compared to both:
- the Prometheus `txs_solved_total` metrics, and
- the actual number of transactions visible in Explorer between the same comparison points.

At least in the observed samples, the Prometheus counters matched the real transaction count while `/mining-status` reported more solved transactions than actually happened.

## Evidence

Example comparison window:
- Between `16:38:29` and `16:40:18`, only `7` transactions were observed in Explorer.
- In the same window, `/mining-status` increased by:
- `cpuminer`: `1033 -> 1035` (`+2`)
- `ccminer`: `39 -> 47` (`+8`)
- `cgminer`: `9 -> 9` (`+0`)
- Total increase reported by `/mining-status`: `10`
- In the same window, Prometheus increased by:
- `cpuminer`: `1098.0 -> 1100.0` (`+2`)
- `unknown` (corresponding to the fast miner observed here): `38.0 -> 43.0` (`+5`)
- `cgminer`: `211.0 -> 211.0` (`+0`)
- Total increase reported by Prometheus: `7`

That Prometheus increase matches the transaction count observed in Explorer, while `/mining-status` overcounts.

## Possible Cause

A likely explanation is that the local miner counter is incremented before the solution is definitively accepted as the unique winning solution.

In `txstratum/protocol.py`, the current flow appears to increment the miner-local transaction counter immediately after `verify_pow()` succeeds:

```python
if obj.verify_pow():
self.manager.submit_solution(self, job, obj.get_struct_nonce())
if obj.is_block:
self.blocks_found += 1
else:
self.txs_solved += 1
```

If a very fast miner submits multiple valid solutions for the same transaction before a new job is issued, the manager may reject later submissions because the transaction was already solved, but `self.txs_solved` may already have been incremented more than once.

This would explain why:
- the overcount is seen in `/mining-status`,
- the manager-level Prometheus metrics remain correct, and
- the effect is more visible on faster miners.

## Expected Behavior

`/mining-status` should only count transactions that were actually accepted as solved, so its counters stay aligned with the authoritative manager-level metrics and with real transaction outcomes.