feat: make per-job timeout 0 mean "no timeout" instead of inherit

A per-job timeout now has three distinct states: unset inherits the global
default, an explicit 0 means no timeout and does not inherit, and a positive
value is the per-job limit. Job.TimeoutSeconds became *int so unset and 0 stay
distinguishable in jobs.json.

Also fixes the global default, which could not persist a 0. loadOrCreateConfig
normalized DefaultTimeoutSeconds <= 0 back to 30 on every read of an existing
gosentry.json, so "no timeout" only held until the next restart. The field is
now written unconditionally (no omitempty) and read back as-is.

Existing jobs and configs are unaffected: a job with no timeout_seconds still
inherits, and a saved global default of 30 stays 30.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

docs/CHANGELOG.md

@@ -2,6 +2,24 @@
 
 All notable GoSentry changes are recorded in this file.
 
+## Unreleased
+
+**Timeouts: 0 now means "no timeout" at both levels.**
+
+- The global **Default timeout** in Settings now defaults to `0`, meaning jobs
+  run to completion with no deadline instead of being killed after 30s.
+- A per-job timeout of `0` now also means "no timeout" and no longer inherits
+  the global default. Leaving the job's timeout **empty** is what inherits.
+  `Job.TimeoutSeconds` became `*int` so the three states — unset, explicit 0,
+  and a positive limit — stay distinguishable in `jobs.json`.
+- Fixed: a global default of `0` did not survive a restart. `gosentry.json` was
+  loaded with `0` treated as a missing value and silently reset to 30s, so the
+  setting only held for the current session. `default_timeout_seconds` is now
+  written unconditionally and read back as-is.
+
+Existing jobs and configs are unaffected: a job with no `timeout_seconds` still
+inherits, and a saved global default of 30 stays 30.
+
 ## 0.13.0 - 2026-07-26
 
 **Branded GoSentry color theme; Cancel/Defaults buttons in Settings.**