fix(automations): save-error banner cleared on failure (follow-up to #369)

[mgoldsborough]

Follow-up to #369. A QA reviewer correctly found that the "surface update errors" half of #369 doesn't actually work — verified against source.

The bug

AutomationDetailView.saveField:

async function saveField(field, value) {
  setEditing(null);
  setError(null);
  try {
    await onUpdate(...);     // rejects
  } catch (err) {
    setError(err.message);   // sets the error
  }
  loadDetail();              // ← runs setError(null) (line 51) before its first await
}

When onUpdate rejects, the catch runs setError(message), then loadDetail() runs synchronously to its first await — executing setError(null). Both updates land in the same microtask continuation, React batches them, null wins, and the banner ({error && …}) never renders. (Even without batching, it's two sequential setErrors and null is last.) Net: a rejected save still looks like a silent no-op — the exact symptom #369 set out to fix.

The fix

Refresh only on success:

try {
  await onUpdate(...);
  loadDetail();            // success path only
} catch (err) {
  setError(err.message);   // persists; no refresh to clear it
}

On failure the error stays set; the field reverts because setEditing(null) closes the inline editor and re-renders the unchanged detail value.

Notes

• The cap-raise half of fix(automations): raise iteration cap to 50, surface update errors #369 (15→50, default 5→25) was unaffected and is correct.
• No regression test: the bundle UIs have no component-test harness (@testing-library); this React state-timing path can't be covered without standing up RTL. Verified manually against the batching trace; bun run verify:static green and the automations bundle UI builds clean.