docs(xdto): устранить противоречие «как править пакет» между навыками

На один и тот же вопрос четыре инструкции отвечали по-разному: decompile
объявлял себя «основным способом менять пакет», edit сам себя занижал
до варианта для маленьких пакетов, compile про edit не упоминал вовсе,
а workflow валидатора его не знал. Модель получала бы разный ответ
в зависимости от того, на какой файл попала, причём два из них уводили
от единственного навыка, созданного ровно для этой задачи.

Единое правило проведено через все четыре: точечная правка — xdto-edit;
переработка схемы целиком или знакомство с ней — decompile → compile.
Заодно в decompile добавлена развилка на xdto-info, чтобы разграничить
«нужна схема» и «нужна сводка для кода».

Мелочи: грамматика в xdto-edit, служебное значение -Mode auto убрано
из таблицы параметров (пользователь его не пишет), описан флаг [до N].

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

.claude/skills/xdto-decompile/SKILL.md

@@ -30,12 +30,15 @@ powershell.exe -NoProfile -File "${CLAUDE_SKILL_DIR}/scripts/xdto-decompile.ps1"
 ... -PackagePath src/XDTOPackages/ОбменСБанком -OutFile bank.xsd
 ```
 
-## Правка пакета
+## Переработка схемы целиком
 
 `/xdto-decompile` → правка XSD → `/xdto-compile -Force` возвращает пакет без потерь,
 включая имя, синоним и комментарий объекта метаданных — они выгружаются
-в `xs:annotation/xs:appinfo`. Это основной способ менять существующий пакет:
-отдельных операций правки не нужно, схема читается и правится целиком.
+в `xs:annotation/xs:appinfo`.
+
+Этот путь нужен, когда схему меняют широко или сначала надо разобраться, как она
+устроена. Чтобы поправить одно свойство, схему целиком читать не нужно — `/xdto-edit`.
+Если нужна не схема, а сводка «что присвоить и что обязательно», — `/xdto-info`.
 
 В схеме могут встретиться атрибуты с префиксом `xdto:` — так записано то, что
 XML Schema выразить не может (например `nillable` у атрибута). Схема при этом остаётся