feat(автосогласование): флаг на шаге маршрута и фоновая задача по SLA

Шаг маршрута получает флаг «Автосогласование» (AutoApprove). Когда у активной
строки такого шага истекает SLA, часовая задача Hangfire принимает за
согласующего положительное решение: помечает строку, двигает очередь и
пересчитывает статус заявки — тем же набором правил, что и портал, когда решение
принимает человек (зеркало approverDecision.service.ts/decide).

Флаг не nullable, в отличие от SLA рядом: наследовать его неоткуда — у типа
заявки такого поля нет и быть не должно.

- ApprovalRow и константы статусов переехали в общий Approvals: их теперь читают
  и напоминания, и автосогласование, разъезжаться разбору одного и того же
  списка нельзя;
- SharePointClient научился MERGE'ить элементы (раньше умел только читать).

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

backend/Tnsu.ApprovalRoute.Application/TemplateRoutes/ResolveTemplateRouteDto.cs

@@ -20,6 +20,13 @@ namespace Tnsu.ApprovalRoute.Application.TemplateRoutes;
 /// текст), это код роли из самого шага маршрута — чтобы вызывающая сторона могла отличить,
 /// например, «директора Tansu» от «руководителя направления», не разбирая Position текстом.
 /// </param>
+/// <param name="AutoApprove">
+/// Согласовать шаг автоматически по истечении SLA. Значение шага маршрута как есть —
+/// наследовать его неоткуда (у типа заявки такого поля нет, см.
+/// TemplateRouteStep.AutoApprove). Вызывающая сторона (request-portal) просто
+/// переносит его в строку списка согласования: решает по нему не она, а фоновая
+/// задача бэкенда (AutoApproveService).
+/// </param>
 public sealed record ResolvedRouteStepDto(
     int Id,
     int OrderNo,
@@ -29,7 +36,8 @@ public sealed record ResolvedRouteStepDto(
     string? Warning = null,
     int? SlaHours = null,
     bool? AskOverdueReason = null,
-    HeadType? PositionCode = null);
+    HeadType? PositionCode = null,
+    bool AutoApprove = false);
 
 public sealed record ResolveTemplateRouteResultDto(
     int RouteId,