PHOENIX-7817 Resolve Omid transaction manager via provider singleton view

[apurtell]

OmidTransactionClient captures the provider's HBaseTransactionManager at construction time. OmidTransactionContext in turn caches that same reference in a private field. When a prior test class shuts down OMID's TSO together with its mini-cluster, the next test class reuses the stale wrapper and is dispatched to the dead executor. The symptom is a RejectedExecutionException originating from the OMID TSOClient state-machine executor.

In production the singleton's manager is set exactly once and never replaced, but the test framework exercises the swap path between classes within a single Surefire/Failsafe fork.

Fix:

OmidTransactionClient becomes a thin view onto the singleton's current HBaseTransactionManager. It resolves
provider.transactionManager on every call to getTransactionClient(). transactionManager is marked volatile so test-framework injection is published to other threads without synchronization.

In production the dynamic lookup is functionally identical to caching.