Coding lab: protected cross-currency payment

How the provided code works

Before you write anything, the read-only helper sets up a tiny practice market so you can focus only on the payment itself. When you press Run, it:

1. Funds two accounts from the Testnet faucet: an issuer (which also acts as the market maker) and a sender (who will pay in XRP).
2. Creates a recipient locally and activates it with a small XRP payment from the issuer, so a run only needs two faucet requests.
3. Posts liquidity: the recipient opens a trust line to the issuer, and the issuer places an offer selling its token (TST) for XRP. This is what lets a payment convert XRP into TST.
4. Finds a path from XRP to TST with ripple_path_find, then hands it to your code.

Your job is the two functions below: build the protected Payment, and read what actually arrived. The console prints each step as it runs so you can see the market being built.

Lab goal

You will pay someone in a token while spending XRP, with guardrails that stop you overspending or accepting a worse fill than you allow. The helper handles the repetitive setup so you can focus on the payment itself.

The exercise spins up a disposable XRP/TST market, asks the network for a path, and pays a recipient in TST from a sender holding XRP. Account funding and market seeding all live in the read-only helper.

Your job is buildProtectedPayment and deliveredAmount. The payment requests 5 TST, caps the source spend at 3 XRP, allows a partial fill only when at least 4.9 TST arrives, and uses the computed path. Print the structured result once, after validation.

Failure checkpoint

Once the happy path works, reason about the edges: what happens if SendMax drops below the available price, or DeliverMin sits too close to the full amount? Trigger one deliberate failure, then read its validated result code and explain it. A provisional response from submit is not the answer here — wait for the validated one.