perf: keep file I/O off Service.mu and untie StartOnly from the app context

Phase 7 of the whole-project review (findings 3.2 and 3.3).

Service.mu is the lock the Fyne main thread takes on every Jobs() and
Runtime() call, so anything blocking inside it makes a UI refresh wait on
the disk. Three things did:

- Every SaveJobs/SaveConfig was a marshal, fsync, and rename under mu.
  Writes are now prepared under the lock (Store.PrepareSaveJobs /
  PrepareSaveConfig snapshot the payload and target path) and run after
  it is released. deferSaveLocked takes saveMu while mu is still held, so
  writes still reach the file in the order their snapshots were taken and
  an older snapshot can never land on top of a newer one.
- executeRun ran runner.CleanupLogs under mu after every run. It needs
  only the values already snapshotted into runEnv, so it now runs after
  the unlock — including when the job is gone, since the run still wrote
  a log file that retention covers.
- adoptJobsLocked ran runner.SeedStats under mu, reached from
  UpdateSettings on the UI thread. Seeding moved out into
  applySeededStatsLocked; UpdateSettings now reads the new jobs file and
  seeds its statistics before taking the lock, and re-checks the
  "no jobs-file switch while running" guard once it has it.

SeedStats also opened every log file twice — once to find the job, again
to read the result. readLogSummary reads job_id, state, and duration in
one pass, so each log is opened once.

StartOnly runs were built with exec.CommandContext on the app's lifecycle
context. os/exec keeps a watcher goroutine alive until Wait returns or the
context is done, and StartOnly never calls Wait, so one goroutine leaked
per run and would then try to kill a process whose handle startJobOnly had
already released. The invocation now uses context.Background(), whose nil
Done channel means no watcher is started at all.

Regression tests: TestRunJobStartOnlyLeavesNoContextWatcher (fails with 5
leaked goroutines on the old code), TestConcurrentJobOperationsLeaveTheFileMatchingMemory,
and TestUpdateSettingsSeedsAdoptedJobsFromLogs. STANDARDS gains the
no-I/O-under-mu rule and the "a StartOnly process outlives GoSentry" entry.

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

src/app/run.go

@@ -147,7 +147,6 @@ func (s *Service) executeRun(ctx context.Context, jobCopy domain.Job, trigger st
 	record, logErr := s.runJob(ctx, &jobCopy, trigger, env.logsDir, env.timeout)
 
 	s.mu.Lock()
-	var cleanupErr error
 	var rerunStarted bool
 	if current := s.findByIDLocked(jobCopy.ID); current != nil {
 		runtime := s.runtimeForLocked(current)
@@ -166,10 +165,15 @@ func (s *Service) executeRun(ctx context.Context, jobCopy domain.Job, trigger st
 		} else {
 			s.refreshNextRunLocked(current, runtime)
 		}
-		cleanupErr = runner.CleanupLogs(env.logsDir, env.maxFiles, env.maxAge)
 	}
 	s.mu.Unlock()
 
+	// Cleanup is a directory scan plus up to MaxLogFiles unlinks. It needs only
+	// the values already snapshotted into runEnv, so it runs after mu is released
+	// rather than making every UI refresh wait behind it. It runs even when the
+	// job is gone, because the run still wrote a log file that retention covers.
+	cleanupErr := runner.CleanupLogs(env.logsDir, env.maxFiles, env.maxAge)
+
 	if logErr != nil {
 		s.emit(ErrorOccurred{Err: fmt.Errorf("write run log for %q: %w", jobCopy.Name, logErr)})
 	}