fix(meta-edit): свойства-списки у заимствованного объекта и не своего типа (#99)

У заимствованного объекта расширения в Properties только изменённые свойства.
add-registerRecord и прочие add-*/set-* над списками не находили элемент, печатали
WARN, файл не меняли и выходили с кодом 0.

- Движения заимствованного документа: отсутствующий RegisterRecords создаётся.
- Прочие списки у заимствованного объекта — отказ. Проверено на 8.3.27: Owners и
  RegisteredDocuments платформа контролирует на равенство основной конфигурации
  (расширение не применяется), BasedOn/InputByString/DataLockFields и движения
  последовательности молча выбрасывает при загрузке.
- Свойство, которого у типа объекта нет (движения у справочника), — отказ; раньше
  modify.properties дописывал его, и meta-validate это пропускал.
- У обычного объекта отсутствие элемента — отказ вместо WARN.
- reference/properties.md: типы объектов в таблице — по выгрузкам ERP, БП, УТ, УНФ.
- verify-snapshots: двухэтапная загрузка и по params.extensionPath кейса.

Co-Authored-By: Roman Syuzyov <rsyuzyov@gmail.com>
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>

tests/skills/verify-snapshots.mjs

@@ -1292,7 +1292,9 @@ async function verifyCase(skillName, caseName, skillConfig, caseData, opts) {
       return result;
     }
 
-    if (CFE_SKILLS.has(skillName)) {
+    // Кейс навыка не из CFE_SKILLS тоже может править расширение (meta-edit над заимствованным
+    // объектом) — признак тот же params.extensionPath.
+    if (CFE_SKILLS.has(skillName) || caseData.params?.extensionPath) {
       // CFE: two-stage load — base config first, then extension.
       // Каталог расширения берём из кейса, а не хардкодим: при жёстком 'ext' кейс, назвавший
       // каталог иначе, молча терял вторую половину проверки — блок ниже обходился по existsSync,