Internal links omit trailing slashes, causing a redirect through unencrypted HTTP

Many internal links in the documentation are written without a trailing slash.
Because the site serves pages as directories, every one of those links triggers
a redirect and that redirect drops the connection to plain HTTP before a
second redirect puts it back on HTTPS.

### Example

https://docs.dyalog.com/20.0/windows-ui-guide/find-and-replace-dialogs/ links to:

https://docs.dyalog.com/20.0/language-reference-guide/pcre-specifications

with no trailing slash. Requesting it produces:

301 -> http://docs.dyalog.com/20.0/language-reference-guide/pcre-specifications/
301 -> https://docs.dyalog.com/20.0/language-reference-guide/pcre-specifications/

Verify with:

curl -IL https://docs.dyalog.com/20.0/language-reference-guide/pcre-specifications

The response headers show the redirect through HTTP:

HTTP/1.1 301 Moved Permanently
location: http://docs.dyalog.com/20.0/language-reference-guide/pcre-specifications/

followed by a redirect back to HTTPS.

The same slashless link to `pcre-specifications` also appears on
https://docs.dyalog.com/20.0/windows-ui-guide/find-objects-tool/, and
https://docs.dyalog.com/20.0/windows-installation-and-configuration-guide/configuration-parameters/configuration-parameters/
links to https://docs.dyalog.com/20.0/object-reference/methodorevents/getenvironment
in the same way.

### Scale

From a Screaming Frog crawl of v20.0 (2026-09-08):

- 616 internal links across 259 pages point at slashless URLs
- 299 unique URLs affected
- 625 two-redirect chains and 16 three-redirect chains
- 603 internal 3xx responses in total, about 15% of all internal requests

### What it causes

- An unencrypted request and response in the middle of the chain. The site
sends no `Strict-Transport-Security` header, so browsers have no instruction
to skip the HTTP hop.
- Three round trips instead of one, for readers and for crawlers.
- Some HTTP clients abandon the request entirely, returning "too many
redirects" rather than the page.

### Fix

Add the trailing slash to internal links in the source markdown. The redirect
then never fires and the insecure hop disappears, without any infrastructure
change.

### Related, separate issue

The reason the redirect is insecure at all is that the server writes `http://`
into the `Location` header regardless of how the request arrived — most likely
TLS terminating at a proxy that forwards to the origin over HTTP, with the
origin building absolute redirect URLs from its own scheme rather than
`X-Forwarded-Proto`. This affects https://docs.dyalog.com/ itself, which
redirects to `http://docs.dyalog.com/20.0/` before being upgraded again, so it
will still need fixing after the links are corrected. That is a hosting
configuration matter rather than a content one.