Confirm changes automatically from the client that made them

A change made over the network answers with a one-time confirm_token
and closes its connection (HTTP/2: a GOAWAY). The web UI and hc send the
token straight back to /confirm, which accepts it only for the newest
change, from the same user and API token, the same address, and over a
new connection: proof that the client can still reach the API through
the new ruleset (an established connection would get through anyway). A
change that cuts its client off can't be confirmed so, and rolls back by
itself. The setting manual_confirm (hc settings set --auto-confirm off)
and hc --no-confirm leave confirming to a person. Changes through the
local socket still need no confirmation. e2e: 136 checks, among them a
lockout change rolled back without anyone confirming.

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

internal/api/types.go

@@ -66,6 +66,11 @@ type MutationResponse struct {
 	// ConfirmBy is set when the change is on probation: unless confirmed
 	// (POST /confirm) by then, it is rolled back.
 	ConfirmBy *time.Time `json:"confirm_by,omitempty"`
+	// ConfirmToken lets the client that made the change confirm it by
+	// itself (POST /confirm {"token"}): from the same address, over a new
+	// connection, which proves it can still reach the API. The answer
+	// closes its connection, so the next request opens a new one.
+	ConfirmToken string `json:"confirm_token,omitempty"`
 	// Diff is the ruleset's unified diff, for a dry run.
 	Diff string `json:"diff,omitempty"`
 	// Staged: the change was added to a changeset (Changeset), not
@@ -318,3 +323,10 @@ type QuotaAddress struct {
 	Address string `json:"address"`
 	Used    int64  `json:"used"`
 }
+
+// ConfirmInput confirms the changes on probation. With Token (a change's
+// confirm_token), it is the client that made the change confirming it by
+// itself; without, a person's confirmation.
+type ConfirmInput struct {
+	Token string `json:"token,omitempty"`
+}