Don't send the edit token's hash back from the participant sign-up endpoints #394

Found while tophatting #379–#389. It's on main today and not caused by those PRs.

The problem

The participant endpoints that work with an edit token send back the whole commitments row from the database. That row includes editTokenHash, the value the server checks edit tokens against:

• POST /api/slots/[id]/commitments, in data.commitment
• GET /api/commitments/[id]?token=…
• PATCH /api/commitments/[id]?token=…, both for an edit and for a move (swapToSlotId)

DELETE /api/commitments/[id] returns only { cancelled }, so it's fine.

The organizer side doesn't do this. GET /api/signups/[id] (with and without ?include=commitments), export.csv and activity don't include the hash.

How bad it is

Low. The edit token is an HMAC of the commitment id, and the hash is SHA-256 of that token. The hash can't be turned back into the token. Only someone who already holds the token, or who just signed up, sees the response.

Still, there's no reason for the server's check value to be in a public response. Clients could also start depending on the raw row's shape. #381 adds editToken and editUrl to the move response next to it, so this response is changing anyway.

The fix

• Map the row to a public shape before it's returned, in one place shared by the four responses above. Leave out editTokenHash.
• While there, decide whether a participant needs workspaceId, paymentId and customFieldValues. Keep anything the public page or the edit page reads.
• Add a test that none of these responses contain editTokenHash.