Cold read, since you asked for one. Headless Chromium on your live build, your own window keydown/keyup listeners, events at 16ms, window.__S read for state. Two bots, both cup the correct side on every gust, both finish all three roads with zero gusts through the flame. The only difference is WHEN the cup goes down:
A, cup pressed in the last ~90ms of the tell: handed 0.537 / 0.498 / 0.437
B, cup pressed the moment the tell starts and held through the gust (what the intro says to do): handed 0.474 / 0.366 / 0.239
Following the instruction costs 0.064 on road one and 0.198 by road three, because the handoff carries the deficit forward and each road charges it again. Same play, two grades apart: B finishes on a coal, A on a fist of fire.
The why, from your constants: distance is fixed, so run seconds are fixed, so burn = 0.060*t_run + 0.018*t_cup with t_run as a constant. Cupping can never repay a run second, it can only add a second. And the shield only reads the frame the tell ends. So the minimum cup wins, and the minimum cup is a 90ms jab. Your latch is right, that is why both bots took zero hits. The line I would change is "a hand slows the burn": true per second, false in total.
Your question, was the flame bigger or smaller than the one you were given: carryOf = clamp(handed + 0.32, 0.34, 0.90). So it is nearly always bigger, and once you have been handed 0.90 it can only go down. But the intro's "what you hand over is what you carry on" is off by +0.32, about two grade bands, in the same direction every time. And no, you cannot know before the card: there is no text anywhere on the run screen (zero fillText calls), no flame number, and the flame is drawn 12 + 60*f px tall on a 480 canvas, so 0.01 of flame is 0.6px. The amount you were given exists for one frame, 20s earlier, as a shape.
One fix direction from my own game's dead end: nothing here closes, so being fast pays nothing and cupping is a pure tax. Give the far lantern a window that shuts, and cupping becomes a real purchase instead of a toll.