fix(runtime): артефакт CF не грузится на Windows — в `/LoadCfg` уходит путь с `\\?\`

[malinovme]

operation=load не может загрузить собранный артефакт: после проверки файла
v8-runner передаёт платформе путь \\?\C:\… как аргумент /LoadCfg. Платформа
показывает его в диагностике как file://\\?\C:\… и отвечает «Файл не
обнаружен». Документированный цикл make → load на Windows невыполним.

Стенд: плагин 0.12.3 (коммит f6d23068), target win-x64, платформа 1С
8.3.27.2325, Windows; source-set main, файловая ИБ.

Замер

make проходит: build/config.cf, 91 534 байта, сигнатура контейнера
FF FF FF 7F 00 02 00 00.

load с относительным путём:

{"operation": "load", "path": "build/config.cf", "mode": "load", "dryRun": false}

load: compatibility probe   — прошёл
load: apply                 — Artifact load failed
platform error: load failed for configuration 'main' with exit code 1;
platform log: Файл не обнаружен
  'file://\\?\C:\Projects\dsh_1c_test\build\config.cf'.
  2(0x00000002): Не удается найти указанный файл.

Повтор с абсолютным путём (C:\Projects\dsh_1c_test\build\config.cf) даёт тот же
ответ посимвольно. Раннер в своём отчёте печатает тот же путь в расширенной
форме:

artifact: \\?\C:\Projects\dsh_1c_test\build\config.cf

Файл при этом существует — размер и заголовок выше; лог платформы
build/logs/platform/load-load.log содержит ровно ту же строку. Отдельный лог
build/logs/platform/artifacts-main-cf.log подтверждает: «Сохранение
конфигурации успешно завершено».

Почему это дефект

В закреплённом v8-runner 0.5.1 (7ce1b062…, asset
v8-runner-nightly-master-build.2) функция resolve_existing_file проверяет,
что артефакт существует и является файлом, после чего вызывает
std::fs::canonicalize. На Windows результат получает verbatim-префикс \\?\.
Затем DesignerDsl::load_cfg без нормализации преобразует Path через
display().to_string() и передаёт его следующим аргументом /LoadCfg.

В коде уже есть normalize_windows_verbatim_path, но на пути артефакта перед
/LoadCfg она не применяется. Платформа показывает полученный аргумент как
file://\\?\… и не открывает его. Контракт /LoadCfg ожидает имя CF-файла;
достаточно передать обычный абсолютный путь без verbatim-префикса.

Отдельно: отказ не различает «файла нет» и «платформа не открыла переданный
аргумент». v8-runner к этому моменту уже доказал, что файл существует и является
файлом, поэтому сообщение «Файл не обнаружен» отправляет диагностировать
несуществующий артефакт и скрывает проблему преобразования пути.

Связь с #355

Симптом artifact_load_failed уже встречался в
#355 (первичная загрузка
расширения, mode=load для .cfe). Причина там другая — классификация результата
проверки совместимости перед применением артефакта. PR
#502 только зафиксировал
принадлежность дефекта и маршрут поставки; его описание прямо говорит, что
поведение не менялось.

Исправляющий патч для #355 принят отдельно в
v8-runner-rust#54,
но плагин 0.12.3 по-прежнему закрепляет старый коммит 7ce1b062… и asset
build.2; сама #355 сейчас открыта повторно. Здесь артефакт проходит проверку
совместимости, но платформа не открывает файл по переданному пути. Первопричины
независимы.

Что делать

1. После canonicalize удалять Windows verbatim-префикс перед передачей пути в
   /LoadCfg и /MergeCfg; для этого уже есть
   normalize_windows_verbatim_path.
2. Проверить тем же замером load для .cfe с extension — путь проходит через
   тот же resolve_existing_file.
3. В ошибке указывать результат собственной проверки: «артефакт найден (91 534
   байта), платформа его не открыла».
4. Добавить Windows-регрессию make → load в чистую файловую базу; отдельным
   случаем проверить путь с кириллицей.

Названный недобор

Работоспособность самого CF после загрузки не подтверждена: прямой запуск
1cv8.exe не использовался. Проверено, что артефакт собран платформой, существует
и имеет сигнатуру CF, а load запускает платформу, но завершается до применения
конфигурации.

Проверка

Два applied-вызова load (относительный и абсолютный путь) дали одинаковый
отказ; make перед ними завершился успешно. При повторной проверке оба варианта
также сформировали одинаковый preview, различающийся только исходным значением
--path. Живой платформенный лог и исходники закреплённой версии v8-runner
согласуются: canonicalize создаёт \\?\…, а /LoadCfg получает этот путь без
нормализации. Логи: build/logs/platform/load-load.log и
build/logs/platform/artifacts-main-cf.log.