Ok! I think I get it now.
You're right, the UDID is, of course, not sent by the browser. I was convinced too it was getted by a security flaw of Safari, or something like that, because testflightapp adds an unique ID similar to UDID, but no.
What they actually do, is generate a new DeviceID (not related with UDID). Then, to register the device, they generate a profile specifically made to this DeviceID, that contains an Enrollment Payload that enrolls the device against an URL that contains this DeviceID generated by testflightapp.
In this enrollment process, the device is asked by the profile, to send the UDID (plus other data). This is the info the profile asks for:
<array>
<string>UDID</string>
<string>IMEI</string>
<string>ICCID</string>
<string>VERSION</string>
<string>PRODUCT</string>
<string>MODEL</string>
<string>DEVICE_NAME</string>
</array>
So, when the device asks to the testflightapp server to enroll this device, they're able to relate that DeviceID stored in the profile, with the actual UDID of the current device. That's how they show in the browser that the process is completed and keep the UDID.
But, this doesn't complete the answer, because I've don't solved (yet) how they actually relate this web session with the UDID, even when the session deads, and the DeviceID goes orphaned. The answer seems to be (not confirmed, but 99% sure!) that the enrollment process allows to define a WebClip to be inserted in your Springboard menu. This WebClip has in the URL written the UDID of the device, so any time you get into the testflightapp through this WebClip, you're refreshing to the session your UDID number, so doesn't matter if the session dies.
Hope my post helps now! Sorry again for the uncomplete-misinformed previous one.