feat: per-job command timeout with global default

Add an optional per-job run timeout following the overlap_policy inherit
pattern: Job.TimeoutSeconds (0 = inherit) resolves against a new
Config.DefaultTimeoutSeconds (default 30s), replacing the hard-coded 30s
guard in runner.RunJob.

- domain/storage: new fields, default 30, load-time normalization
- runner: RunJob takes an explicit timeout; StartOnly stays untimed so it
  keeps measuring launch latency only
- app: effectiveTimeout resolves under mu into runEnv, threaded to runJob;
  seam signature and validation updated; DisplayTimeout helper
- ui: Timeout entry in the job dialog, Default timeout in Settings, and a
  Timeout row in the details panel
- tests + docs (ARCHITECTURE, STANDARDS, ROADMAP, CHANGELOG) updated;
  version bumped to 0.12.0

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

docs/ARCHITECTURE.md

@@ -87,8 +87,9 @@ flowchart LR
 
 5. Command execution:
    `runner.RunJob` builds the platform-specific invocation, executes the
-   command through the platform shell, captures stdout and stderr, writes one
-   timestamped `.log` file, and returns a `domain.RunRecord` containing
+   command through the platform shell under the caller-supplied timeout, captures
+   stdout and stderr, writes one timestamped `.log` file, and returns a
+   `domain.RunRecord` containing
    `DurationMS` (wall-clock milliseconds from start to finish; for `StartOnly`
    fire-and-forget jobs it measures launch latency — the time to spawn the
    process — since there is no exit to wait for).
@@ -128,6 +129,19 @@ in flight increments `JobRuntime.PendingRuns`. When the current run finishes,
 `executeRun` drains the counter by starting one deferred run per completion until
 `PendingRuns` reaches zero.
 
+### Per-job command timeout
+
+`domain.Job` carries a `TimeoutSeconds` field (`json:"timeout_seconds,omitempty"`),
+following the same inherit pattern as the overlap policy. `0` means inherit the
+global `Config.DefaultTimeoutSeconds` (default **30**); a positive value overrides
+it for that job alone. `app.Service.effectiveTimeout` resolves the effective
+duration under `mu` and `startRunLocked` snapshots it into `runEnv.timeout`.
+`runner.RunJob(ctx, job, trigger, logsDir, timeout)` takes the resolved duration
+as an argument, so the runner stays ignorant of the global config: it applies the
+timeout via `context.WithTimeout` and reports `Timed out after <timeout>` on
+expiry. `StartOnly` jobs run on the untimed context and so measure launch latency
+only, unaffected by the run timeout.
+
 ### Run-time statistics
 
 `domain.JobRuntime` holds a rolling aggregate updated after each run: