MVV

Вкратце: не заморачивайтесь.
В ремесле программирования есть полезный принцип, обозначаемый англоязычным сокращением YAGNI, что в переводе означает "Вам это не понадобится." Согласно этому принципу, раз вы не знаете, как можно использовать Expression с параметром-типом не являющимся делегатом, то вам вряд ли понадобится его так использовать.
А проверки параметра-типа там нет, скорее всего, потому что эта функциональность (она называется Expression trees) появилось давно, больше 15 лет назад, в .NET Framework 3.5, а тогда в .NET проверки параметра-типа ЕМНИП не было.
Но, подозреваю, что попытка использовать в качестве TDelegate не тип-делегат просто приведет к ошибке: почти наверняка - при попытке получить исполняемый код из выражения (метод Compile), а, возможно, и раньше - или при попытке создания объекта, или даже на этапе написания кода или компиляции: ее может (да или нет - не проверял) обнаружить анализатор при компиляции исходного кода и даже IntelliSense. И подозреваю, что при попытке обойти дерво такого объекта Expression tree (это - альтернативный способ использования этой функциональности), тоже будет ошибка - ибо выражение получается бессмысленным.
В любом случае, истиной в последней инстанции является исходный код. Если вам так уж захотелось узнать, что будет - читайте исходный код: он лежит на GitHub, ссылка есть в документации по классу в learn.microsoft.com (сразу предупреждаю: там все сложно).

Сколько там недочетов. потенциальных ошибок. неверных решений?

1. У вас намешаны синхронная - в с одном потоке с блокировками (Wait, Sleep) - и асинхронная (async/await) многозадачность Теоретически, совмещать их можно, но лучше остановиться на каком-то одном подходе - легче будет. Синхронное выполнение задач (каждая - в своем потоке, который она блокирует по необходимости) - это проще, но асинхронное выполнение (при которм поток не блокируется, а освобождается, а задача планируется для продолжения после завершения операции в свободном потоке) позволяет получить больше производительности. Вот и выбирайте, что вам нужнее.
2. Для синхронизации используйте не переменные (а, к примеру, isRun у вас используется именно для этого), а объекты синхронизации. В частности, isRun следует заменить на объект синхронизации. Для синхронного выполнения лучше всего IMHO подойдет ManualResetEventSlim. для асинхронного - что-нибудь, на чем можно сделать await (например, TaskCompletionSource.Task).
3. Любой доступ к совместно используемым в разных задачах объектам(ресурсам) следует синхронизировать путем захвата связанного с ресурсом объекта исключающего доступа. Для синхронного выполнения подойдет оператор lock (вижу, что вы его уже используете). Для асихронного выполнения lock можно использовать, но - только если в его теле нет await (и компилятор вам не позволит нарушить это правило). Не пытайтесь обойти это правило, используя вместо lock другие объекты синхронизации, подразумевающие захват владения на уровне потока (Monitor, Mutex...) - компилятор всего лишь не сможет вам помешать сделать ошибку. В таком случае для синхронизации можно использовать SemaphoreSlim, но это требует понимания и аккуратности, поэтому подробности пока не пишу.
Думаю, пока этой информации к размышлению вам хватит.

Простейший способ решить вашу задачу - найти того, кто ее вам решит: человека - за деньги, по дружбе и пр. - или ChatGPT и т.п. LLM. Человека искать - это не здесь (если на Хабре, за деньги - то есть раздел Freelance).

Если же вам почему-то хочется решить задачу самому, и нужна подсказка, то, прежде всего, задачу надо сформулировать, примерно - как в математике: что дано и что требуется получить. А потом - задать конкретный вопрос по тому, что мешает вам решить. Если это не сделать, то придется вам ждать помощи телепата или ясновидящего.

В частности (я не телепат, но попробую угадать), если вам мешает неудобная работа с TimeSpan, то стоит вспомнить (или узнать), что он представляет собой число фиксированных мелких промежутков времени, именуемых tick. Вы можете прочитать это число в его свойстве Ticks, работать с ним как с обычным числом - не только сравнивать, но и умножать, делить, складывать, вычитать - а потом, если надо, перевсти обратно в TimeSpan методом TimeSpan.FromTicks.

PS Если будете описывать задачу, лучше всего пользуйтесь не автоматически даваемыми названиями элементов интерфейса - dateTimePicker2, textBox6 и пр. - а названиями указывающими на их смысл - лучше всего их переименовать соответствующим образом, это - крайне рекомендованная практика при программировании вообще.

А вам точно это нужно?
Потому что тут у вас появляется нюанс, который не совсем ложится на схему работы веб-приложения: у ваших отдельных запросов появляется общее состояние. Как минимум, это - накапливаемый пакет запросов, а ещё, наверное, в это состояние входит нечто общее для всех запросов для работы с БД: подключение или, если используется Entity Framework, DbContext. Это общее состояние придется как-то хранить, регулировать доступ к нему (DbContext к примеру, параллельный доступ не поддерживает в принципе), и вовремя это состояние удалять. Если посмотреть на стандартные механизмы ASP.NET Core, то сессия (ISession) для этого, наверное, не подойдет - там можно хранить только сереализуемые в байты пассивные объекты, и насчет регулировки доступа там непросто. Подойдет концентратор (Hub) SignalR, у которого есть сохраняемый между вызовами контекст подкючения - но ради него, скорее всего, потребуется менять способ вызова API из браузера: у него там своя клиентская библиотека.
Ну и, по-любому, как-то надо реализовывать активную часть - которая, собственно, отслеживает пакет изменений и вовремя отправляет его в БД.
Ваша идея

Шедуллер в фоне будет периодически читать коллекцю объектов на запись и устанавливать результат выполнения в соотвтвующий TaskComplitionSource.

мне не совсем нравится. Зачем периодически? Kучше чтобы эта активная часть срабатывала по факту добавления запроса в пакет - например, асинхронно ожидала Task от TaskComplitionSource. который метод добавления запроса завершал бы по факту добавления завершающего пакет запроса. Но и завершение по таймауту тоже предусмотреть надо - по жизни оно всякое бывает: обычно для таких целей используется WaitAny для комбинации основной ожидаемой задачи с Delay по таймауту.
Ну, а ещё требуется, наверное, чтобы для каждого пользователя состояние было свое. В принципе, это делается, но надо делать. Для SignalR для этого можно использовать Hub.Context.Items - это словарь, который может содержать произвольные объекты, и сохраняется на время действия всего подключения.

А ещё у меня, в принципе, есть своя самодельная библиотека, которая решает ту же задачу - сохранение контекста сеанса, в том числе - активного, с выполняющимся кодом. Я описывал ее недавно в статьях (кроме основной статьи есть дополнительная) на Хабре. Можете попробовать её, если переделывать API не хочется: она вполне годится для работы с API на базе MVC API Controller. или Minimal API. В принципе, она заточена немного под другую задачу - получние и возврат дополнительных результатов в фоне, но для вашей задачи она тоже подойдет. Напишу тут сразу технические подробности как использовать: ссылку на активную часть, собирающую и отправляющую пакет, можно хранить в IActiveSession.Properties, точно так же, как если бы вы хранили ее в Hub.Context.Items, а обработчик завершения, который прибирает за собой (в SignalR его место в OnDisconnect) - привязать к IActiveSession.CompletionToken через его метод Register. В общее для всез запросов состояние входит свой контейнер сервисов со своей областью действия в течение всего существования состояния, так что, если для работы с БД требуется Scoped-сервис из DI-контейнера, то его можно получить оттуда (в дополнительной статье написано, как, а также написано, как защититься от нежелательного одновременного доступа к такому сервису).

Только вот библиотека эта, естественно, ни разу не стадартная, use at your own risk. Но если попробуете ее, мне будет интересно, что получилось. В том числе - и обнаруженные ошибки, заодно я и для вас их исправлю :-) .

PS И неплохо было бы IMHO, чтобы дальнейший диалог, если он будет, шел на русском языке, без "батч", "эвейтить", "шедулер" и прочих транслитераций, IMHO лучше уж по-английски писать, если перевод неизвестен. А то я человек старый, мне читать этот пиджин тяжеловато.

PPS А ещё благодарю за идею, о том, в какую сторону мне развивать мою библиотеку.

Абстрактно "правильного" варианта реализации нет, всё зависит от конкретных деталей.
В частности, посмотрите, используют ли ваши методы действий одни и те же внешние зависимости, или каждый - свои. Во втором случае некотоый смысл разнести их по разным контролерам есть: снизить сложность, которую дают лишние, не обусловленые задачей связи (coupling). А первом случае - нет (но может и появиться по другим основаниям).

А вся эта теория "чистой архитектуры" - она абстрактная. Ее полезно знать, чтобы иметь возможность рассмотреть больше вариантов решения, и видеть больше про возможных подводных камней, а вот фанатично ей следовать не стоит (если, конечно, ваша задача - сделать что-то полезное, а не спихнуть курсовик и т.п.).

Причина ошибки, как пишется в сообщении о ней - переполнение стека. Размер стека для потогков определяется процессом, в котором работает приложение. Обычно он фиксирован и записан в заголовке .exe. Если при размещении веб-приложения в своем процессе (так делается запуск из Visual Studio) стека хватает, то настройте размещение приложения вне процесса и в IIS: документация - здесь, по умолчанию AFAIK для IIS используется размещение приложения ASP.NET Core внутри его рабочего процесса, и используется размер стека этого рабочего процесса.

PS А вообще, я бы на вашем месте пересмотрел код миграций и использовал стек (локальные переменные методов имеющие тип значений, память, отводимая через stackalloc и т.п.) в нем по минимуму. Потому как требования к памяти приложения имеют свойство расти со временем, а стек задается фиксированной величиной.

Привыкли к миксинам в языке с динамической типизацией? В C# их нет, и вряд ли будут, потому что типизация тут статическая. И приемы программирования - соответственно, другие.

В частности, чтобы добавить дополнительное свойство (или метод) в классы из разных иерархий наследования, используйте интерфейс. Примерно так (примеры - на основе кода из комментариев):

public interface IChosable {
    bool IsChosen {get; set;}  //Желательно имена писать таки на английском правильном
                                             // а не ломаном. А то глаза режет.
                                             //Ну, или хотя бы - по русски транслитом: 
                                             // Vybrano вместо IsChoised - и то лучше, IMHO
}

//...
    public class ViewedDirectoryData : DirectoryDataEntity, IChosable
    {
        public bool IsChosen {get; set;}  
    }

    public class ViewedOutputData : OutputData, IChosable
    {
        public bool IsChosen {get; set;}  
    }

Но свойства, таки да, придется определять в каждом классе, реализующем интерфейс (но можно перенести их, вместе с указанием реализации интерфейса, в базовые классы иерархий).

Удобство тут в том, что ссылку на любой из классов, реализующих интерфейс, можно привести к типу интерфейса - тогда и статический контроль типов сохраните, и работать со всем этими классами можно будет единообразно.

Вы неправильно понимаете класс enum. enum - это не класс, а ключевое слово языка C#.

PS

И я задумался:

Надо не думать, и даже - не знать. Надо - уметь применять. Подумайте, какую практическую задачу вы хотели решить этой задумкой? Если такой задачи нет - не забивайте себе голову. А если желаете забить себе голову чисто для себя чем-нибудь абстрактным, то для этого лучше всего подойдет философия, а не IT.