Stop 500ing when a service account acts on an incident

Every incident-mutation handler read userFromContext(ctx) and wrote the
result's .ID into acknowledged_by/incident_events.user_id without checking
the ok bool. For a team-scoped service-account caller this returned a
zero-value user id, which violated the users(id) FK and 500'd on
acknowledge, unacknowledge, resolve, snooze, unsnooze and create-note.
handleDeleteNote didn't crash but silently matched zero rows instead
(WHERE user_id = 0), so a service account could never delete its own note.

Add acknowledged_by_service_account_id (incidents) and service_account_id
(incident_events) as nullable FKs to service_accounts(id), parallel to and
mutually exclusive with the existing human columns (migration 015, with a
CHECK enforcing the exclusion). Route every one of the six handlers plus
delete-note through a new callerActorIDs() helper that branches on
Caller.AsHuman()/ServiceAccountID() instead of assuming a human, and thread
a serviceAccountID parameter through logEvent and the new
acknowledgeIncidentAs (acknowledgeIncident itself is untouched: its only
other caller, the push-notification Acknowledge button, is always human).
Render the new actor distinctly from both a human and "the server acted"
in the web UI's incident timeline and facts card.

handleIncidentAssign, handleIncidentArchive and handleIncidentUnarchive are
deliberately not touched here — they track no actor at all today, for
anyone, which is a separate pre-existing gap (follow-up issue to come).

Fixes #25

internal/models/incident.go

@@ -43,6 +43,13 @@ type Incident struct {
 	AcknowledgedByUser *string    `json:"acknowledged_by,omitempty"`
 	AcknowledgedAt     *time.Time `json:"acknowledged_at,omitempty"`
 
+	// AcknowledgedByServiceAccountID/Name are the service-account-shaped
+	// parallel to AcknowledgedByID/User above: mutually exclusive with it,
+	// populated when a service account (not a human) acknowledged this
+	// incident. See migration 015 and terdut-server#25.
+	AcknowledgedByServiceAccountID   *int64  `json:"acknowledged_by_service_account_id,omitempty"`
+	AcknowledgedByServiceAccountName *string `json:"acknowledged_by_service_account,omitempty"`
+
 	AssignedToID   *int64  `json:"assigned_to_id,omitempty"`
 	AssignedToUser *string `json:"assigned_to,omitempty"`
 
@@ -67,17 +74,27 @@ type Incident struct {
 // and is the only history this server keeps — alert rows are mutated in place.
 //
 // Type is one of: triggered, alert_added, alert_resolved, acknowledged,
-// unacknowledged, assigned, snoozed, unsnoozed, resolved, note. A nil UserID
-// means the server acted rather than a person.
+// unacknowledged, assigned, snoozed, unsnoozed, resolved, note. UserID and
+// ServiceAccountID are mutually exclusive; both nil means the server acted
+// rather than any caller.
 type IncidentEvent struct {
-	ID         int64     `json:"id"`
-	IncidentID int64     `json:"incident_id"`
-	Type       string    `json:"type"`
-	UserID     *int64    `json:"user_id,omitempty"`
-	Username   *string   `json:"username,omitempty"`
-	AlertID    *int64    `json:"alert_id,omitempty"`
-	Detail     *string   `json:"detail,omitempty"`
-	CreatedAt  time.Time `json:"created_at"`
+	ID         int64   `json:"id"`
+	IncidentID int64   `json:"incident_id"`
+	Type       string  `json:"type"`
+	UserID     *int64  `json:"user_id,omitempty"`
+	Username   *string `json:"username,omitempty"`
+
+	// ServiceAccountID/Name are the service-account-shaped parallel to
+	// UserID/Username above: mutually exclusive with it, populated when a
+	// service account (not a human, and not nil-meaning-the-server-acted)
+	// performed this event. Named Name, not Username — a ServiceAccount has
+	// a Name field, not a Username. See migration 015 and terdut-server#25.
+	ServiceAccountID   *int64  `json:"service_account_id,omitempty"`
+	ServiceAccountName *string `json:"service_account_name,omitempty"`
+
+	AlertID   *int64    `json:"alert_id,omitempty"`
+	Detail    *string   `json:"detail,omitempty"`
+	CreatedAt time.Time `json:"created_at"`
 }
 
 // SimilarIncident is an earlier, resolved incident with the same signature as