Is Z-man's PTLC construction implementable using libsecp256k1-zkp?
My question is whether this MusigTweak is what is called the adaptor (last argument of secp256k1_musig_session_combine_nonces) in secp256k1-zkp?


No, what "Z-man" refers to as MusigTweak is not called the adaptor in secp256k1-zkp. The difference between the normal MuSig ritual and the "almost entirely MuSig" ritual is not the MuSigTweak. The MuSigTweak just determines how keys are aggregated and is called secp256k1_musig_coefficient in the secp256k1-zkp implementation as of commit cad7cc8f34d17166da2dabae20188ea6e747ac69. In the MuSig paper the MuSigTweak is called a_i. The adaptor argument of secp256k1_musig_session_combine_nonces refers to t*G (where G is the base point) in Z-man's description.


  And has in fact been implemented?


Yes, almost. What Z-man is describing here is the original adaptor signature scheme. It's not well suited for multi-hop locks (aka Lightning with payment points), because the creating party must know the t when creating an adaptor signature. Therefore, the implementation in libsecp256k1-zkp uses the adaptor signature variant that was introduced in the original Lightning in Scritpless Script mailing list post and in the Anonymous Multi-Hop Locks for Blockchain Scalability and Interoperability paper. If you want to know more about the multi-hop lock protocol, I suggest to have a look at the diagram in the scriptless script repo.

libsecp256k1-zkp has a unit test for a scriptless script atomic swap using that technique.


  How is MusigTweak computed? Is it the per-hop tweaked payment point, which means it will be the payment point for the hop connecting to the payer?


The adaptor point t*G is the per-hop tweaked payment point, not the MuSigTweak.