[Feature]: Add JWT Bearer authorization

[LunatikDG]

Какую задачу решаем / Problem to solve

Нет способа сгенерировать JWT (header.payload.signature) из полей (алгоритм, secret/приватный ключ, claims) и отправить его как Bearer-токен. Нужен HMAC (HS256/384/512) как минимум, в идеале RS256 (RSA) для совместимости с реальными API.

Предложение / Proposed solution

1. Проверить, какие крипто-примитивы доступны из BSL "из коробки": ХэшированиеДанных (SHA-1/256/512) есть; HMAC и RSA-подпись, скорее всего, потребуют либо КриптоМенеджер (нужен установленный крипто-провайдер на клиенте/сервере — не всегда есть), либо ручную реализацию HMAC поверх ХэшированиеДанных (реализуемо для HMAC-SHA256).
2. Первая итерация: только HS256 (HMAC-SHA256), т.к. не требует внешнего крипто-провайдера — реализовать HMAC вручную по RFC 2104 поверх встроенного SHA-256.
3. Схема авторизации: поля Алгоритм (пока только HS256), Секрет, Claims (JSON) (произвольные payload-поля), плюс автогенерация стандартных iat/exp (TTL в настройках).
4. Тип правила в реестре схем (ОписаниеСхемыАвторизации) — потребуется новый вид правила (не описательный шаблон, а функция, вычисляющая JWT на сервере перед отправкой) — расширить движок правил новым видом, например ComputedHeader, с серверной функцией-обработчиком.

Альтернативы / Alternatives considered

No response

Дополнительно / Additional context

No response

[LunatikDG]

Progress (partial)

Merged in 1.3.25 via #28 (depends on #27).

Done in this release

• JWT Bearer UI + schema (JwtBearer)
• HS256 / HS512 (HMAC via platform hashing)
• Claims JSON, TTL → iat / exp
• Auth core in object module; Postman jwt import/export for HS*

Still open (follow-up)

• RS* (asymmetric) algorithms
• HS384 (if still desired)
• Any other items from the original issue scope

Leaving this issue open until the remaining algorithms/scope are decided or implemented.