How does MuSig work in real Bitcoin scenarios? Questions on communication and steps

Signature Generation

1. Let L = h(P1 || ... || Pn). Each participant computes the digest: ai = h(L || Pi).
2. Compute the aggregated public key: X̃ = Σ (ai * Pi) for i = 1, ..., n. X̃ is made public.
3. Each participant randomly selects ri and computes: Ri = ri * G. Each participant sends their commitment: ti = h(Ri) to all other participants.
4. After receiving the other n-1 commitments, each participant sends their point Ri.
5. After receiving the other n-1 points Ri, each participant verifies: ti = h(Ri) for all i ∈ {1, ..., n}.
6. Calculate the aggregated point: Rsum = R1 + ... + Rn.
7. Each participant computes the challenge: c = h(Rsum || X̃ || M).
8. Each participant calculates their partial signature: si = ri + c * di * ai mod N.Finally, compute the aggregated signature: ssum = s1 + ... + sn mod N.
9. The signature is the pair (Rsum, ssum).

Signature Verification
Check if:
ssum * G = Rsum + c * X̃.

Questions:

1. Sharing ti, Ri, and si: How do participants send their commitments (ti), share their Ri values, and exchange partial signatures (si)? What does this process look like in practice? Is there a standard, asynchronous, and user-friendly way to manage this in software? Or do participants need to manually compute their si, sum them, and share the results back and forth?
2. Verification Process: Who verifies the final signature (Rsum, ssum)? When and how does this verification happen in real-world Bitcoin use cases? Is the verification done via P2SH scripts? And regarding the initiation of the verification process—does a participant (e.g., one of the multisig signers) who has collected all the Rsum and ssum values create the transaction from the P2SH address? Or am I misunderstanding this flow?
3. What Happens Without Commitments? What could an adversary do if the commitments (ti) were not part of the protocol? What kind of attacks could occur, and how would they exploit the lack of commitments?