hooks: read-then-write race on first-save webhook token generation #43

Follow-up from review on #30 (feat(backend): add webhook trigger).

In syncTriggerIndex (workflows.go), the webhook case does GetTriggerIndexEntry → if empty, generate a token → Upsert, with no transaction/locking. Two concurrent first-saves of the same new workflow could each generate a different token and race on the upsert, silently discarding one — indistinguishable from an unrequested rotation.

This is a narrow window: the frontend save button is :disabled="saving" for the duration of the request, so triggering it requires two genuinely separate save actions racing at the network level, not a simple double-click. That's why it wasn't fixed as part of #30 — not worth bolting on new locking/SQL surface speculatively for a low-likelihood race.

Possible fixes, if this turns out to matter in practice:

• Wrap syncTriggerIndex's webhook case in a mutex (cheap, but only helps within a single process).
• An atomic "preserve existing token" SQL upsert, distinct from RotateWebhookToken's deliberate overwrite — would need its own query.