TxnHandler heartbeat txn doesn't need serializable DB txn level

What it does is:
1) Update lock heartbeat time, fails if not found.
2) Get txn state.
3) If not found, look for txn in completed, fails regardless of result.
4) Update txn heartbeat time if not (3) and not aborted.

All this can run the same under repeatable-reads.
Now if it runs under read-committed, someone could
1) update txn state after we read it
2) delete txn state (moving to completed) after we read it
3) same for completed state
In case of 1 we will update heartbeat for e.g. aborted txn without detecting it. UPD: We can change queries to detect it
In case of 2 the update will produce 0 rows so we will detect that and can check completed as we already do.
The 3 case seems like it doesn't matter.

I don't know if (1) matters. These heartbeats happen often and can cause contention on the db