redirects: follow best practices

From the [Gemini best practices](https://gemini.circumlunar.space/docs/best-practices.txt):

> ### Redirect limits
>
> Clients may prompt their users for decisions
as to whether or not to follow a redirect, or
they may follow redirects automatically. If
you write a client which follows redirects
automatically, you should keep the following
issues in mind.
>
> Misconfigured or malicious Gemini servers may
serve redirects in such a way that a client
which follows them blindly gets trapped in an
infinite loop of redirects, or otherwise has
to complete a very long chain of redirects.
Robust clients will need to be smart enough
to detect these conditions and act
accordingly. The simplest implementation is
to refuse to follow more than N consecutive
redirects. It is recommended that N be set
no higher than 5. This is inline with the
original recommenation for HTTP (see
RFC-2068).
>
> ### Cross-protocol redirects
>
> Cross-protocol redirects (i.e. redirects from
Gemini to something else, like Gopher) are
possible within Gemini, but are very heavily
discouraged. However, misconfigured or
malicious servers will always be able to
serve such redirects, so well-written clients
should be ready to detect them and respond
accordingly.
>
> It is strongly recommended that even clients
which generally follow redirects
automatically alert the user and ask for
explicit confirmation when served a redirect
to a non-TLS-secured protocols like HTTP or
Gopher, assuming the client implements
support for these protocols. This avoids
unintentional plaintext transfers.

Start by locating the client and server entry points that handle Gemini redirects; the issue does not name files or tests. Compare the redirect behavior with the linked Gemini best practices, then verify that redirect chains are bounded and that redirects to non-TLS protocols receive explicit user confirmation.

Written by the indexing model from the issue text.