fix: map 'timed out' race rejection to 504 instead of generic 500

[eprouveze]

What

The submit route's own 25s timeout race rejects with the message "Database operation timed out", but the error mapping below only checks for the substrings "timeout" and "deadline" — "timed out" (with a space) matches neither. So when a large-history merge blows the 25s window, the client gets the generic catch-all 500 "Failed to submit data. Please check your cc.json file format..." instead of the intended 504 "Request timed out. Please try again or submit smaller batches of data."

That message difference matters: the 500 sends users down a payload-format rabbit hole, while the 504 tells them the actual fix (smaller batches).

How I hit this

My account (eprouveze) has a ~188-day history. Since the #43/#79 per-machine merge deploy, mergeWithExisting runs one sequential daily_breakdowns round-trip per incoming day, so a full-history re-submit merging into an existing ~180-day record can exceed the 25s race. Every attempt returned the generic 500 with a payload that field-diffs identical to my last accepted submission (June 10, pre-deploy) — I only found the real cause by reading this route's source. Splitting the same data into ≤60-day chunks submits fine.

Notes

• Fix is intentionally minimal: add "timed out" to the existing substring check (plus a comment tying it to the race above).
• Possible follow-up (not in this PR): batching the per-day loop in mergeWithExisting (e.g. a single upsert on (submission_id, date)) would remove the timeout for long-history users entirely.

🤖 Generated with Claude Code

https://claude.ai/code/session_01CprMNM6BjWgqLGcmCjZVZJ

[vercel]

@eprouveze is attempting to deploy a commit to the sculpt Team on Vercel.

A member of the Team first needs to authorize it.