Does modification order contribute to happens-before relationship?

No. there is no happens-before relationship between Operation 1 and Operation 3.

From [atomics.order]/2:

An atomic operation A that performs a release operation on an atomic object M synchronizes with an atomic operation B that performs an acquire operation on M and takes its value from any side effect in the release sequence headed by A.

... and unfortunately, Operation 2 is not in the release sequence headed by Operation 1 according to [intro.races]/5:

A release sequence headed by a release operation A on an atomic object M is a maximal contiguous sub-sequence of side effects in the modification order of M, where the first operation is A, and every subsequent operation is an atomic read-modify-write operation.

As a result, we cannot build any inter-thread happens-before relationship between Operation 1 and other operations, so there is no happens-before relationship between Operation 1 and Operation 3.

If I understand your question correctly, no there is no extra guarantees on overall ordering as a result of what memory ordering you use. There is no blocking at-all to allow this to happen.

In your example, you show thread 1 and thread 2 both operating on x in exactly the same way. Therefore, the relationship between thread 1 and thread 3 should be exactly the same as the relationship between thread 2 and thread 3.

Your example does not show any code lines that would constrain the order in which the three operations actually would happen. In other words, just from looking at those three statements, there is no way to say whether the load operation would return 1, or 2, or some previous value of x.