fix(workflows): fill in the activity timeouts a workflow left unset

[KillerX]

4/n of a stack. Base: refactor/remove-xml-ingest-entrypoint (#442).

A workflow only has activity options if it called workflow.WithActivityOptions, and nothing tells the author when it did not: activities are mostly reached through helpers like CreateFolder or WriteFile rather than through an Execute call in view. Four registered workflows are in that position — BulkExportShorts, ExportShort, ImportSubtitles and MoveFilesWorkerFlow (the audit listed the first three) — and Execute backfilled only ScheduleToCloseTimeout.

Two consequences:

• StartToCloseTimeout stayed zero, so the server falls back to the schedule-to-close budget. A single attempt is allowed to run the full three hours, and the ten-attempt retry policy above it has nothing left to retry into.
• That three hours is a number nobody chose. Every workflow that does call WithActivityOptions gets 4h/12h from GetDefaultActivityOptions, so the workflows that forgot ran under a tighter, quieter regime than the ones that did not.

Execute now fills any unset timeout from GetDefaultActivityOptions, and so does ExecuteWithLowPrioQueue, which had no timeout backfill at all — latent only because both its callers happen to set options.

HeartbeatTimeout is deliberately left alone. Filling it in would put a ten-minute heartbeat timeout on activities that never call RecordHeartbeat, turning a slow success into a certain failure, and Execute cannot tell which activities heartbeat. (That is its own finding — activities/vizualizer.go is already in exactly that trap.)

Verified: with the old backfill the no-options workflow reports a 3h attempt budget where the test expects 4h.

🤖 Generated with Claude Code