OK, I understand better. I think? :
The WE locks the private key to some external condition (a fraud proof; a certificate of something that unlocks a vault, etc. - your various examples) being proved true. Then with the multisig component the spending transaction’s structure can be defined/controlled by a third party.
So the idea is that, by combining the two, you get a sort of “mix” of two desirable properties: the covenant-like behaviour is enforced by the 3rd party at any time (so as you say, early, at “setup” will be especially convenient), while that third party is not responsible for checking the spending condition or gate (such as the fraud proof being valid), that part is done automatically with WE.
So I guess I do see why you think the term ‘covenant’ makes sense here.
I guess the only unfortunate thing is that even if it is done in an early “setup” phase, this construction does require the user to be funding into a multisig in that setup phase. Depending on the use case that could be completely normal or not.