Дедуп исполнителей резолва — по Guid сотрудника, не по email

Реальная причина бага с дублем в списке согласования: один и тот же
человек может иметь несколько email в справочнике api.tnsu.kz, поэтому
схлопывание по email его не ловило.

EmployeeDirectoryInfo дополнен полем Id (Guid сотрудника из /Employee/
ByEmail). ResolveStepAsync теперь параллельно с email несёт этот Id
(внутренний ResolvedStepRow, наружу не отдаётся), а CollapseByExecutorIdentity
и RemoveCompanyDirectorsDuplicatedByDirectorTansu дедуплицируют по
identity-ключу: Id, если он резолвился, иначе email как фолбэк (на случай,
если сотрудник по итоговому email не нашёлся в справочнике).

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

backend/Tnsu.ApprovalRoute.Infrastructure/TnsuPortal/TnsuPortalDtos.cs

@@ -2,7 +2,16 @@ using Tnsu.ApprovalRoute.Domain.Enums;
 
 namespace Tnsu.ApprovalRoute.Infrastructure.TnsuPortal;
 
-public sealed record EmployeeDirectoryInfo(Guid CompanyId, Guid? DepartmentId, string Company, string? Position);
+/// <param name="Id">
+/// Guid сотрудника в справочнике api.tnsu.kz — один и тот же человек может иметь
+/// несколько записей (см. массив в /Employee/ByEmail) и даже несколько разных
+/// email, но Id у него один. Используется как надёжный ключ дедупликации
+/// исполнителей при резолве маршрута (см. TemplateRouteService) — email для
+/// этого не годится: один человек может фигурировать под разными адресами.
+/// Nullable, потому что старые вызовы могли не запросить это поле явно (сейчас
+/// всегда приходит) — на этот случай дедуп по Id тихо откатывается на email.
+/// </param>
+public sealed record EmployeeDirectoryInfo(Guid CompanyId, Guid? DepartmentId, string Company, string? Position, Guid? Id = null);
 
 public sealed record ProjectExecutorInfo(ProjectRole ProjectRole, string Email);