feat: propagate CFG_LDAPS_HOST through setup and document LDAPS networking (#71)

Pass optional CFG_LDAPS_HOST from setup.env through setup.sh into the
generated ./config/sso-secrets.js as ldap.ldapsHost. This lets operators
advertise an internal-only LDAPS hostname (e.g. ldap.internal.example.com
or sso-manager) on the SSO /integrations page instead of the public
OAuth issuer, avoiding a public 636 port forward.

- setup.env.example: add CFG_LDAPS_HOST
- setup.sh: read/forward CFG_LDAPS_HOST into sso-secrets.js
- config.example/sso-secrets.js.example: document ldapsHost/ldapsPort
- .env.example: add LDAPS_HOST for legacy .env migrations
- docker-compose.yml: comment warning against public 636 forwarding
- README.md: explain CFG_LDAPS_HOST recommendation
- CHANGELOG.md + bump version to 1.1.19

Co-authored-by: Claude <noreply@anthropic.com>

README.md

@@ -120,6 +120,10 @@ Optional extra ports (only if you need them):
 - **636** (LDAPS) — only if a legacy app on another machine binds to LDAP
   directly over the network. The proxy itself reaches LDAP over the internal
   Docker network, so you do **not** need to expose 636 for the stack to work.
+  **Do not forward 636 to the public internet.** If you need LAN clients to bind
+  LDAP, set `CFG_LDAPS_HOST=ldap.internal.example.com` (or `sso-manager` for
+  same-host Docker clients) in `setup.env` and use an internal DNS record / cert
+  SAN. The default shows the public SSO hostname, which implies a public route.
 
 ### 4. Docker + Docker Compose