fix(routines): add missing feedback after trigger create/save

[LArtistaDMorte]

Problem

Two silent-failure UX bugs in RoutineDetail.tsx on the paperclip-routines branch:

1. Save trigger — clicking Save on an existing trigger updates the backend correctly but shows no confirmation toast. Users have no feedback that the save worked.

2. Add trigger — after clicking "Add trigger", the form stays populated (appears like nothing happened) and no toast is shown for schedule triggers. Webhook triggers correctly show the secret banner, but schedule triggers get nothing.

Fix

• updateTrigger.onSuccess: add pushToast({ title: "Trigger saved", tone: "success" })
• createTrigger.onSuccess: add success toast for non-webhook triggers + reset newTrigger state back to defaults so the form visually clears

Testing

1. Open a routine with no triggers
2. Add a schedule trigger → should see "Trigger added" toast and form resets
3. Edit the trigger label → click Save → should see "Trigger saved" toast

[greptile-apps]

Greptile Summary

This PR adds two missing UX feedback signals in RoutineDetail.tsx: a "Trigger saved" toast after a successful updateTrigger mutation, and a "Trigger added" toast + form reset after a successful createTrigger mutation for non-webhook triggers. The fix is minimal (3 lines added), the reset values exactly match the component's initial state, and the existing error-toast paths are untouched.

Key points:

• updateTrigger.onSuccess: straightforward addition of pushToast({ title: "Trigger saved", tone: "success" }) — no issues.
• createTrigger.onSuccess: toast correctly placed in the else branch (webhook path already shows the secret banner instead). The setNewTrigger reset is placed outside the if/else, meaning it also runs for webhook trigger creation — this is a minor behavioural change worth confirming (the form snaps back to kind: "schedule" after a webhook is added, which may or may not be desired).
• PR description note: The description covers the problem, fix, and testing steps, but is missing the "thinking path" required by CONTRIBUTING.md, and there are no before/after screenshots for the toast changes. Please add these to help reviewers and maintainers.

Confidence Score: 5/5

Safe to merge — changes are minimal, correct, and contained to two mutation callbacks.

All findings are P2. The only code note is a deliberate-vs-accidental question about resetting the form for webhook triggers too; it does not break anything. The PR description is missing CONTRIBUTING.md's thinking path and screenshots, but that is a process note, not a code defect.

No files require special attention.

Important Files Changed

Filename	Overview
ui/src/pages/RoutineDetail.tsx	Adds success toasts to createTrigger and updateTrigger onSuccess handlers, and resets the new-trigger form after creation. Reset values exactly match initial state; changes are minimal and correct.

Prompt To Fix All With AI

This is a comment left during a code review.
Path: ui/src/pages/RoutineDetail.tsx
Line: 482

Comment:
**Form also resets for webhook triggers**

`setNewTrigger(...)` is now unconditionally called for both webhook and schedule trigger creation. For webhook triggers this means the form resets even though the user is shown the `secretMessage` banner (which is fine UX), but it is a behaviour change versus the pre-PR code. It's worth confirming this is intentional: should a webhook creator be able to create a second webhook immediately after without re-selecting the "webhook" kind from the dropdown? Currently the form snaps back to `kind: "schedule"` for both paths.

If the reset for webhook triggers is not desired, moving the call inside the `else` block is the minimal fix:

```suggestion
      setNewTrigger({ kind: "schedule", cronExpression: "0 10 * * *", signingMode: "bearer", replayWindowSec: "300" });
```
(no change needed — just flagging so it's a conscious decision rather than an accidental side-effect)

How can I resolve this? If you propose a fix, please make it concise.

_{Reviews (1): Last reviewed commit: "fix(routines): add missing feedback afte..." | Re-trigger Greptile}

[greptile-apps]

Form also resets for webhook triggers

setNewTrigger(...) is now unconditionally called for both webhook and schedule trigger creation. For webhook triggers this means the form resets even though the user is shown the secretMessage banner (which is fine UX), but it is a behaviour change versus the pre-PR code. It's worth confirming this is intentional: should a webhook creator be able to create a second webhook immediately after without re-selecting the "webhook" kind from the dropdown? Currently the form snaps back to kind: "schedule" for both paths.

If the reset for webhook triggers is not desired, moving the call inside the else block is the minimal fix:

Suggested change

	setNewTrigger({ kind: "schedule", cronExpression: "0 10 * * *", signingMode: "bearer", replayWindowSec: "300" });
	setNewTrigger({ kind: "schedule", cronExpression: "0 10 * * *", signingMode: "bearer", replayWindowSec: "300" });

(no change needed — just flagging so it's a conscious decision rather than an accidental side-effect)

Prompt To Fix With AI

This is a comment left during a code review.
Path: ui/src/pages/RoutineDetail.tsx
Line: 482

Comment:
**Form also resets for webhook triggers**

`setNewTrigger(...)` is now unconditionally called for both webhook and schedule trigger creation. For webhook triggers this means the form resets even though the user is shown the `secretMessage` banner (which is fine UX), but it is a behaviour change versus the pre-PR code. It's worth confirming this is intentional: should a webhook creator be able to create a second webhook immediately after without re-selecting the "webhook" kind from the dropdown? Currently the form snaps back to `kind: "schedule"` for both paths.

If the reset for webhook triggers is not desired, moving the call inside the `else` block is the minimal fix:

```suggestion
      setNewTrigger({ kind: "schedule", cronExpression: "0 10 * * *", signingMode: "bearer", replayWindowSec: "300" });
```
(no change needed — just flagging so it's a conscious decision rather than an accidental side-effect)

How can I resolve this? If you propose a fix, please make it concise.