I’d still probably advise letting Caddy maintain a trusted certificate, since it costs nothing and precludes self-signed MITM attacks, but I’m glad to hear you’ve got things working!
By way of an explanation: Full (strict) only connects via HTTPS on port 443 and requires Caddy provide a valid certificate (which it can’t do yet since it still needs to solve an ACME challenge and acquire one). You can use this mode with Caddy, just not the first time you run it on each site - Caddy renews certificates early in the tail end of validity so HTTPS is set-and-forget once you’ve got it running in this mode.
Flexible only connects via HTTP on port 80, but provides the client with valid HTTPS. Either this mode or Off (not secure) mode is required the first time you add your site to Caddy (unless you use DNS validation), because Caddy can’t solve TLS-ALPN challenges behind Cloudflare (since Cloudflare terminates HTTPS), so it requires HTTP challenges to solve.
Once the solving is complete for the first run, though, Caddy will start trying to redirect the client up HTTP->S. This is the part that produces a redirect loop; the client is already trying to connect on HTTPS, but Cloudflare is connecting on HTTP only, hence continuous redirection. So, you’ll need to swap it back off this mode after the challenge is first solved.
TL;DR: The ideal scenario is to use Flexible to solve the ACME challenge the first time, then go to Full (strict) afterwards as Caddy can maintain a certificate in Full (strict) mode, but can’t acquire a fresh one.
Alternately, leave the site in Full (strict) mode but grey-cloud your website for the first run, then orange-cloud it after Caddy has acquired a certificate, for a similar result.