docs(modeling): исправлены ссылки на папки и markdown для сайта

- Зачем:
  - относительные ссылки на каталоги sql/ и data/ давали 404 на GitHub Pages;
  - em-dash в заголовках нарушает правило AGENTS.md (расходятся слаги GitHub/MkDocs);
  - 2-пробельная вложенность и списки без пустой строки ломали рендер в MkDocs
- Что:
  - ссылки на папки заменены на GitHub-tree-ссылки (работают на обеих платформах);
  - в 26 заголовках « — » заменено на «: » или убрано (README, SCD, DataVault, домашка);
  - пустая строка перед списком «Главные правила» в DataVault;
  - вложенные списки DataVault переведены на 4-пробельный отступ
- Проверка:
  - mkdocs build --strict (без ошибок);
  - grep по репо — якорных ссылок на старые слаги заголовков нет;
  - grep по site/dwh-modeling/*.html — списки рендерятся <ul>/<li>, вложенность сохранена

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

dwh-modeling/DataVault.md

@@ -126,17 +126,18 @@ erDiagram
 
 Чуть менее «сказочно», чуть более технично.
 
-### 3.1. Hub — сущность и её бизнес-ключ
+### 3.1. Hub: сущность и её бизнес-ключ
 
 **Hub** содержит:
 
 * бизнес‑ключ (customer_bk, order_id, contract_number);
 * техническую информацию:
-  * record_source — из какой системы пришла первая запись;
-  * load_dttm — когда запись попала в DV;
-  * иногда — хэш бизнес‑ключа (hk_customer).
+    * record_source — из какой системы пришла первая запись;
+    * load_dttm — когда запись попала в DV;
+    * иногда — хэш бизнес‑ключа (hk_customer).
 
 Главные правила:
+
 * один бизнес‑ключ — один хаб (одна строка на сущность, без истории);
 * хаб не знает про атрибуты (имя, email) — только идентичность.
 
@@ -153,7 +154,7 @@ CREATE TABLE hub_customer (
 
 Конкретные типы данных (`BYTEA`, длины `VARCHAR`, детали `hashdiff`) и реализации хэш‑ключей можно не запоминать: на старте важнее понять саму идею — у сущностей есть стабильные ключи, а все изменения атрибутов мы записываем отдельными версиями в сателлитах.
 
-### 3.2. Link — связи между сущностями
+### 3.2. Link: связи между сущностями
 
 **Link** описывает факт связи, например:
 
@@ -178,7 +179,7 @@ CREATE TABLE link_order_customer (
 );
 ```
 
-### 3.3. Satellite — атрибуты и история
+### 3.3. Satellite: атрибуты и история
 
 **Satellite** хранит:
 
@@ -249,7 +250,7 @@ Star Schema]
 * **Raw Vault** — это про приём и хранение данных «как есть», но уже в форме Hub / Link / Satellite.
 * **Business Vault** — это про приведение этих данных в более «деловой» вид: с бизнес-правилами, PIT/Bridge и подготовленными представлениями.
 
-### 5.1. Raw Vault — «всё прилетевшее, аккуратно разложенное по ящичкам»
+### 5.1. Raw Vault: «всё прилетевшее, аккуратно разложенное по ящичкам»
 
 Raw DV — первый слой поверх STG / ODS:
 
@@ -261,20 +262,20 @@ Raw DV — первый слой поверх STG / ODS:
 
 * минимум бизнес-логики:
 
-  * никаких правил вроде «клиент активен, если была хотя бы одна покупка за 90 дней»;
+    * никаких правил вроде «клиент активен, если была хотя бы одна покупка за 90 дней»;
 * все источники показываются «как есть», только приведены к общим ключам;
 * структура стабильна: добавился новый источник → появился новый Satellite к тому же Hub.
 
-### 5.2. Business Vault — «там, где из Lego собирают модули»
+### 5.2. Business Vault: «там, где из Lego собирают модули»
 
 Business Vault (BV) — следующий слой над Raw DV:
 
 * здесь применяются бизнес-правила (что считать активным клиентом, как трактовать статусы);
 * здесь строятся вспомогательные структуры:
 
-  * PIT-таблицы,
-  * Bridge-таблицы,
-  * агрегаты и derived-таблицы.
+    * PIT-таблицы,
+    * Bridge-таблицы,
+    * агрегаты и derived-таблицы.
 
 Именно из BV чаще всего строятся витрины в формате Звезды, к которым подключаются BI и отчётность.