fix(cacbg): преходът от режима преди #309 е декларирано оттегляне, не находка

[todorkolev]

Какво

Snapshot заявката в load.mjs вече оставя null за връзка без ред в interest_link_evidence, вместо
да я маскира с текущата RULES_VERSION. Гейтът за монотонност в audit.mjs вече чете това като
декларирано оттегляне и отпечатва точно основанието "the pre-evidence regime — predates §8 and #309".

Защо

interest_link_evidence е добавена от #309 (acfcdcef). Връзки, публикувани преди това, нямат ред в
нея - на staging това са всички 103. Snapshot заявката прави LEFT JOIN и мапваше липсата с
r.rules_version ?? RULES_VERSION. Схемата държи rules_version TEXT NOT NULL, значи fallback-ът се
задейства САМО при LEFT JOIN пропуск, тоест точно на прехода.

Ефектът: първото пълно пускане към staging след бумването (32736025202) стигна до одита с 731/731
присъди и 277 публикувани, но гейтът отчете:

## monotonicity — 103 published last run, 277 now; 37 regression(s), 0 declared removal(s)

Режимът, който беше публикувал тези 103, вече не съществува. tr-rules-2 изисква регистърно
доказателство, а те нямат такова, защото таблицата не е съществувала. Но fallback-ът вкарваше
tr-rules-2 за всичките - гейтът виждаше "изчезнала при непроменена версия" вместо "изчезнала при
смяна на режима".

Поправката

Три части, всяка обяснена в коментарите:

1. load.mjs: премахнат ?? RULES_VERSION. rules_version е NOT NULL в схемата, така че липсата
   винаги означава "няма ред", което е точно преходният случай. Пази null и предава семантиката.
2. audit.mjs: declaredRemoval вече чете null !== RULES_VERSION → true. Изричен клон в
   съобщението назовава основанието с думи ("the pre-evidence regime"), вместо да отпечатва "rules
   change (null → tr-rules-2)".
3. Тестове (два): в audit.test.mjs - snapshot с rules_version: null → декларирано оттегляне и
   думите се появяват. В load.test.mjs - симулира преходния случай (изтрива реда за евидиране
   между две пускания) и чака null в експортирания snapshot. Убива връщането на fallback-а.

Всичко: 46 минават. Работният път (връзка с ред за евидиране) не се променя - fallback-ът е бил
неактивен при него от NOT NULL нататък.

Какво следва

При пускането след сливането: гейтът вижда 103-те стари като декларирани оттегляния, минава, а
пътят продължава към Apply schema → Ship → Reindex. sigma-stage.midt.bg/conflicts се напълва.

Извън обхвата

Дали 37-те стари връзки трябва пак да се публикуват под tr-rules-2 е отделен въпрос за
методологията, не за гейта. Ако да - от следващото пускане ще имат ред за евидиране и ще се държат
нормално.

[github-actions]

Test coverage

Workspace	Lines	Δ	Branches	Δ	Functions	Statements
apps/etl	75.43%	+1.43pp	63.52%	+5.32pp	70.00%	74.11%
apps/web	91.07%	+0.07pp	82.44%	+0.04pp	91.30%	89.75%
packages/config	92.85%	+0.05pp	72.22%	+0.02pp	92.85%	89.18%
packages/db	94.55%	+0.05pp	79.34%	+0.04pp	87.29%	91.58%
packages/ingest	89.71%	+3.41pp	85.52%	+5.12pp	81.74%	88.14%
packages/shared	95.50%	+0.00pp	80.83%	+0.03pp	92.30%	89.56%
Total (informational)	91.43%	—	81.30%	—	87.21%	89.32%

✅ No workspace dropped below its baseline (tolerance 0.5pp).

📈 Coverage rose by more than 1pp — run node scripts/check-coverage.mjs --update locally and commit coverage-baseline.json to ratchet the threshold up.

[lyubomir-bozhinov]

Гейт-фиксът е коректен — проверих го при e72aab1b. null rules_version от LEFT JOIN пропуск наистина може да е само прех-#309 връзка (interest_link_evidence.rules_version е NOT NULL), а насочването ѝ към „декларирано оттегляне" (null !== RULES_VERSION, с null-клона пръв за точното основание) спира фалшивото падане на монотонността точно за този еднопосочен преход. Двата теста го заковават.

Едно нещо за отделна проверка — не блокер на този PR, и въпрос към #309 rebuild-а, не към гейта: 37-те връзки, които изпаднаха от публикувания сет при прехода (103 → 277 публикувани, но 37 от старите ги няма). Гейтът вече минава по тях като „оттеглени по регимен преход" — което е вярно САМО ако всичките 37 наистина не покриват evidence бара на #309 (нямат document/confirmed ред след rebuild-а). Ако някоя е истинска връзка, която rebuild-ът просто не е ре-evidence-нал, тя тихо изчезва от публичната повърхност — оттеглянето е безопасната посока за libel, но е загуба на истинска прозрачност (същия клас като 23-те върнати в #226).

Струва си еднократен spot-check на staging: за 37-те link_key — има ли след rebuild ред в interest_link_evidence с evidence_kind IN ('document','confirmed')? Ако има и пак са изпаднали → publish/гейтът ги дропва по друга причина, която трябва да се хване; ако нямат → оттеглянето е коректно и въпросът е затворен.