Well, 16 days later and we have liftoff! 
…sort of 
The clues that led me to a ‘solution’…
I looked a little deeper into ca_root_nss:
root@caddy:~ # pkg info -l ca_root_nss
ca_root_nss-3.63:
/etc/ssl/cert.pem
/usr/local/etc/ssl/cert.pem.sample
/usr/local/openssl/cert.pem.sample
/usr/local/share/certs/ca-root-nss.crt
/usr/local/share/licenses/ca_root_nss-3.63/LICENSE
/usr/local/share/licenses/ca_root_nss-3.63/MPL20
/usr/local/share/licenses/ca_root_nss-3.63/catalog.mk
…and then appended root.crt to ca-root-nss.crt:
root@caddy:~ # cat /.local/share/caddy/pki/authorities/local/root.crt >> /usr/local/share/certs/ca-root-nss.crt
I then restarted frontend Caddy and noticed a change in the log regarding the trust of the root cert:
{"level":"info","ts":"2021-05-20T13:13:14.114+0800","msg":"shutting down apps, then terminating","signal":"SIGTERM"}
{"level":"warn","ts":"2021-05-20T13:13:14.114+0800","msg":"exiting; byeee!! 👋","signal":"SIGTERM"}
{"level":"info","ts":"2021-05-20T13:13:14.117+0800","logger":"tls.cache.maintenance","msg":"stopped background certificate maintenance","cache":"0xc000315d50"}
{"level":"info","ts":"2021-05-20T13:13:14.118+0800","logger":"admin","msg":"stopped previous server","address":"tcp/localhost:2019"}
{"level":"info","ts":"2021-05-20T13:13:14.118+0800","msg":"shutdown complete","signal":"SIGTERM","exit_code":0}
{"level":"info","ts":1621487594.170676,"msg":"using provided configuration","config_file":"/usr/local/www/Caddyfile","config_adapter":"caddyfile"}
{"level":"warn","ts":1621487594.1781077,"msg":"input is not formatted with 'caddy fmt'","adapter":"caddyfile","file":"/usr/local/www/Caddyfile","line":2}
{"level":"info","ts":"2021-05-20T13:13:14.181+0800","logger":"admin","msg":"admin endpoint started","address":"tcp/localhost:2019","enforce_origin":false,"origins":["localhost:2019","[::1]:2019","127.0.0.1:2019"]}
{"level":"info","ts":"2021-05-20T13:13:14.181+0800","logger":"tls.cache.maintenance","msg":"started background certificate maintenance","cache":"0xc0003ce5b0"}
{"level":"info","ts":"2021-05-20T13:13:14.191+0800","logger":"http","msg":"server is listening only on the HTTPS port but has no TLS connection policies; adding one to enable TLS","server_name":"srv0","https_port":443}
{"level":"info","ts":"2021-05-20T13:13:14.191+0800","logger":"http","msg":"enabling automatic HTTP->HTTPS redirects","server_name":"srv0"}
{"level":"info","ts":"2021-05-20T13:13:20.993+0800","logger":"pki.ca.local","msg":"root certificate is already trusted by system","path":"storage:pki/authorities/local/root.crt"}
{"level":"info","ts":"2021-05-20T13:13:20.993+0800","logger":"http","msg":"enabling automatic TLS certificate management","domains":["xenografix.com.au","acme.lan","www.readymcgetty.com.au","www.caffigoalkeeping.com.au","readymcgetty.com.au","www.udance.com.au","udance.com.au","www.xenografix.com.au","caffigoalkeeping.com","*.udance.com.au","www.caffigoalkeeping.com","caffigoalkeeping.com.au"]}
{"level":"info","ts":"2021-05-20T13:13:20.993+0800","logger":"tls","msg":"cleaning storage unit","description":"FileStorage:/.local/share/caddy"}
{"level":"warn","ts":"2021-05-20T13:13:20.994+0800","logger":"tls","msg":"stapling OCSP","error":"no OCSP stapling for [acme.lan]: no OCSP server specified in certificate"}
{"level":"info","ts":"2021-05-20T13:13:20.997+0800","logger":"tls","msg":"finished cleaning storage units"}
{"level":"info","ts":"2021-05-20T13:13:21.001+0800","msg":"autosaved config (load with --resume flag)","file":"/.config/caddy/autosave.json"}
{"level":"info","ts":"2021-05-20T13:13:21.001+0800","msg":"serving initial configuration"}
Successfully started Caddy (pid=64612) - Caddy is running in the background
Accessing the test site… Nice! 
However, I don’t see anything in the frontend or backend Caddy logs unless I turn
debug on. It would be nice to have some basic logging happening for mTLS.
The system trust solution I stumbled upon is semi-permanent at best. The clue was in this FreeBSD bug report Bug 160387 - security/ca_root_nss: Allow user to trust extra local certificates. The trust breaks if the ca_root_nss package is updated. To fix it, it’s necessary to append root.crt to ca-root-nss.crt again. For reasons described in the bug report, a permanent solution is unlikely to be forthcoming.
Question: How do I convince myself that the communication path between the backend and frontend Caddy services is actually encrypted?