Targets section: one Add, then a target type and Next, then that type's fields (closes #370)

The targets section of the webhook page showed its add form open with every field, a URL included for types that use none. It now lists only its targets until "+ Add" is clicked; "+ Add" shows a choice of target type with Next and Cancel on one row, and Next shows the name and only that type's fields. The database and log types show no URL field and the server stores none for them; the slack form gains its retry field. A refused target brings the page back with the form open on its type, the values entered and the reason, and Cancel empties it. An encoding failure stays a logged 500. Target validation returns its message, so the new-webhook page can reuse it.

Model: opus-5-5

internal/handlers/target_retries.go

@@ -90,13 +90,14 @@ func retriesErrorMessage(err error) string {
 		", or 0 for fire-and-forget"
 }
 
-// targetMaxRetries reads and validates max_retries from a target form
+// targetMaxRetries reads and validates max_retries from a target edit
 // submission, answering the request with a 400 and reporting false
 // when the value is set but invalid.
 //
-// Both the create and the edit path go through here, so the two
-// cannot come to disagree about what a valid retry count is. The
-// wording matches the timeout control on the same submission.
+// It and the create path (newTarget) both use parseMaxRetries and
+// retriesErrorMessage, so the two cannot come to disagree about what a
+// valid retry count is. The wording matches the timeout control on
+// the same submission.
 func targetMaxRetries(
 	w http.ResponseWriter,
 	r *http.Request,