Реестр мультирабочих пространств демона, этап 1

Summary

На этапе 1 внедряется внутренний реестр единой среды выполнения для qwen serve, а также два ограничительных механизма, упомянутых в issue #6378: идентификация на уровне демона и обработка повторяющихся входных данных --workspace. Демон по-прежнему обслуживает ровно одно основное рабочее пространство. Поведение маршрутов/API остается неизменным, за исключением того, что множественные явные значения --workspace теперь приводят к явной ошибке, а не попадают в старый путь для одного рабочего пространства. Имя файла лога демона и идентификатор экземпляра сервиса телеметрии также намеренно меняются с идентификации на уровне рабочего пространства на идентификацию на уровне демона; в примечаниях к релизу PR необходимо указать на эту миграцию.

Реестр станет будущей внутренней границей для внедрения мультирабочих пространств из issue #6378, но на этом этапе намеренно избегается расширение протокола/схемы и не включается поведение CLI для мультирабочих пространств.

Design

WorkspaceRuntime оборачивает текущие объекты serve для одного рабочего пространства: workspaceCwd, AcpSessionBridge, DaemonWorkspaceService, фабрику файловой системы REST-маршрутов и текущий реестр отправителей client-MCP.
WorkspaceRegistry предоставляет только primary, list() и точный поиск getByWorkspaceCwd().
createServeApp сначала собирает существующий стек bridge/service/fsFactory, а затем оборачивает его в primary runtime.
Существующие app.locals.fsFactory и app.locals.boundWorkspace остаются на месте для текущих файловых маршрутов. Добавляется app.locals.workspaceRegistry.
Модули маршрутов сохраняют свои текущие сигнатуры. Уровень сборки сервера теперь передает значения из workspaceRegistry.primary.
Имена файлов логов демона и идентификаторы экземпляров сервиса телеметрии привязаны к демону (serve-<pid>.log, daemon:<pid>). Хеш рабочего пространства остается атрибутом записей лога/телеметрии, а не частью идентификации демона.
runQwenServe принимает возможную форму среды выполнения yargs, где workspace является массивом. Одиночное значение по-прежнему ведет себя как существующее единственное рабочее пространство; множественные значения вызывают ошибку при загрузке до тех пор, пока не будет включена поддержка мультирабочих пространств.

Bounds

Поддержка повторяющихся --workspace пока отсутствует; повторяющиеся значения отклоняются.
Нет workspaces[] в /capabilities или статусе демона.
Изменения типов SDK отсутствуют.
Множественные маршруты /workspaces/:workspace/... отсутствуют.
Отсутствуют индекс владения сессиями, env overlay, maxTotalSessions или поведение воркеров ACP/voice/channel с учетом рабочего пространства.

Audit Notes

Фабрика файловой системы маршрутов называется routeFileSystemFactory, потому что в production сейчас разделяется доступ к файлам через bridge и доступ к файлам через REST-маршруты. Реестр не должен стирать эти границы.

ClientMcpSenderRegistry на этом этапе остается текущей картой одного демона в рамках процесса. Среда выполнения хранит только существующий экземпляр; изоляция client-MCP на уровне рабочего пространства — это задача для более поздних этапов мультирабочих пространств.

SessionArchiveCoordinator и WorkspaceRememberTaskLane остаются текущими участниками сборки сервера. Они не входят в основные задачи реестра на этапе 1.

Middleware телеметрии демона теперь определяет cwd рабочего пространства во время запроса, даже если на этапе 1 всегда происходит разрешение в primary. Это сохраняет текущее поведение, избегая при этом замыкания на хеш основного рабочего пространства, которое станет некорректным после внедрения маршрутов, учитывающих рабочее пространство.

Verification

Целевые тесты охватывают точный поиск в реестре, предоставление locals в createServeApp, сохранение внедренной фабрики файловой системы маршрутов, поведение locals существующих файловых маршрутов, идентификацию лога/телеметрии на уровне демона, хеширование рабочего пространства во время запроса, формы одиночного/повторяющегося --workspace в yargs, путь массива для одного рабочего пространства и защиту от загрузки при повторяющемся --workspace. Финальная проверка должна включать запуск целевых тестов serve, а также сборку репозитория и проверку типов.