fix: use OS trust store for TLS verification via truststore

Regression from #62: verify_ssl true used to resolve to the system CA
bundle path, so corporate CAs installed in the OS worked; after the
unification true became requests' default (certifi), breaking setups
with a corporate CA in the system store.

Now verify_ssl true injects truststore, so requests verifies against
the OS trust store on any platform. verify_ssl false / custom CA path
behavior is unchanged. Tests mock truststore via an autouse fixture to
keep the pytest process free of global ssl mutation.

Refs #62

docs/CONFIG.md

@@ -103,14 +103,15 @@ email:
 
 | Значение | Поведение |
 |---|---|
-| `true` (по умолчанию) | Стандартная проверка TLS средствами requests (системные CA / certifi) |
+| `true` (по умолчанию) | Проверка по системному хранилищу CA операционной системы (через truststore) — корпоративные CA, добавленные в ОС, работают без настройки |
 | `false` | Проверка отключена — при запуске выводится предупреждение о риске MITM |
 | строка с путём, например `/etc/ssl/my-ca.pem` | Путь к собственному CA-bundle, передаётся в requests как есть |
 
 До версии с унификацией `verify_ssl: true` подставлял захардкоженный путь
-`/etc/ssl/certs/ca-certificates.crt`, который отсутствует на части
-дистрибутивов. Теперь `true` в YAML и `REDMINE_VERIFY=true` в env работают
-одинаково — оба включают стандартную проверку без привязки к конкретному пути.
+`/etc/ssl/certs/ca-certificates.crt`, который существует только в
+Debian/Ubuntu. Теперь `true` в YAML и `REDMINE_VERIFY=true` в env работают
+одинаково — оба включают проверку по системному хранилищу CA на любой ОС
+(через truststore), без привязки к конкретному пути.
 
 ### `period.precision` — точность периода