## Why

Пользователь обнаружил, что в клиентах Tusky и Mastodon адрес его аккаунта
отображается как `@kpa39l@social.dedinit.ru` (длинный), хотя ожидался короткий
`@kpa39l@dedinit.ru`. Дополнительно: в феде виден только свой пост, и нужно
открыть регистрацию на инстансе (до 10 пользователей в день).

## Investigation

Разбор показал:

1. **Корень проблемы с адресом** — статический WebFinger на apex-домене:
   - Инстанс (GtS) настроен split-domain: host=`social.dedinit.ru`,
     account-domain=`dedinit.ru`. Сам GtS отдаёт корректный webfinger:
     `https://social.dedinit.ru/.well-known/webfinger?resource=acct:kpa39l@dedinit.ru`
     → `subject: acct:kpa39l@dedinit.ru` (короткий).
   - Но клиенты (Tusky/Mastodon) при резолве `@kpa39l@dedinit.ru` ходят на
     **apex** `dedinit.ru/.well-known/webfinger`, где лежал **статический**
     `index.html` с захардкоженным JSON про `estorozhenko` (игнорировал
     `resource`). Клиент получал ответ про другого пользователя → показывал
     фолбэк-адрес на основе host (`social.dedinit.ru`).
2. **Регистрация** была закрыта: `/api/v1/instance` → `registrations: false`,
   `approval_required: true`.
3. **SMTP** настроен (smtp.jino.ru:587, social@dedinit.ru), но не проверялся.

## Solution

### 1. Динамический WebFinger на apex (Jino)

Apex обслуживается на Jino (Apache, без PHP/SSH-exec). Проверено: **mod_alias
`RedirectMatch` работает**. В `.htaccess` (webroot `/.well-known/webfinger/`)
добавлен редирект:

```
RedirectMatch 301 ^/\.well-known/webfinger(.*)$ https://social.dedinit.ru/.well-known/webfinger$1
```

Теперь `dedinit.ru/.well-known/webfinger?resource=...` отдаёт 301 на GtS,
который динамически резолвит ЛЮБОЙ аккаунт (включая будущих пользователей) —
короткий адрес `@user@dedinit.ru` восстанавливается для всех клиентов.

Аналогичный редирект добавлен для `/.well-known/nodeinfo`.

`host-meta` на apex уже указывал на template `social.dedinit.ru/.well-known/webfinger`
— оставлен.

### 2. Регистрация (10 пользователей/день)

В `docker compose.yml` (env GTS_*):

- `GTS_ACCOUNTS_REGISTRATION_OPEN: "true"`
- `GTS_ACCOUNTS_REGISTRATION_DAILY_LIMIT: "10"`
- `GTS_ACCOUNTS_REGISTRATION_BACKLOG_LIMIT`: не задан → дефолт 20 (очередь
  одобрения). При желании можно поставить явно.

`approval_required` остаётся `true` (GtS по умолчанию требует одобрение админом
новых аккаунтов; при лимите 10/день очередь управляема).

### 3. Проверка SMTP

SMTP-конфиг проверен тестовым письмом: smtp.jino.ru:587 STARTTLS,
auth social@dedinit.ru → письмо успешно отправлено на kpa39l@yandex.ru.
SMTP работает, проблем нет.

## Files Changed

- `docker-compose.yml` (gotosocial): +2 env registration
- `static/.well-known/webfinger/.htaccess` (dedinit.ru): RedirectMatch 301
- `static/.well-known/nodeinfo/.htaccess` (dedinit.ru): RedirectMatch 301
- Jino webroot: удалён статический `index.html` из `/.well-known/webfinger/`
  (заменён .htaccess-редиректом)

## Verification

- `curl -L 'https://dedinit.ru/.well-known/webfinger?resource=acct:kpa39l@dedinit.ru'`
  → `subject: acct:kpa39l@dedinit.ru` (короткий)
- `curl -L 'https://dedinit.ru/.well-known/webfinger?resource=acct:estorozhenko@dedinit.ru'`
  → `subject: acct:estorozhenko@dedinit.ru`
- `curl 'https://social.dedinit.ru/api/v1/instance'` → `registrations: true`
- SMTP-тест: OK