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

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.

Read syncTriggerIndex in workflows.go, focusing on the webhook path from GetTriggerIndexEntry through token generation and Upsert. Compare this with RotateWebhookToken and determine the project’s concurrency and persistence conventions before choosing a fix. Done means concurrent first saves preserve one token without silently treating the race as a rotation, with regression coverage for that behavior.