Regarding the TLS 1.3 Handshake Protocol:
What you ask is not specific to TLS 1.3. Certificate validation is used for all the other TLS versions too and is also used outside of TLS, for example in S/MIME.
I believe I read the Client has the Certificate Authority data stored locally, so it doesn't need to connect to the CA.
Correct. The idea is that the client knows which CA it will trust and has these root CA certificates already for path validation.
If we assume this is Linux, what path is this file, what does it have stored and in what format? Is it a file containing key-value pairs?
There is not central file which is used by all applications. Browsers come with their own trust store, programming languages like Java or Python use their own. Other tools use the certificates in the directory /etc/ssl/certs/, but even this path might vary between Linux distributions.
Formats are different though, some use simple PEM files, some used directories which might also be optimized for lookup using pre-hashed certificates, but some have other formats for key store.
And are we simply comparing a string (the certificate hash?) just received from the server, with a string within the file?
The signature on each certificate in the chain is validated using the public key in the issuer CA. How exactly signature validation works depends on the signature algorithm and the type of public key, but this is not a simple string comparison. See How does the digital signature verification process work? for more.
I've also seen reference to certificate chains. How does this affect the process?
A chain means that there are multiple certificates involved in building the path to the trusted root CA, i.e. something like server-intermediate-root. In this case the signature in the server certificate is validated using the public key in the intermediate (issuer of server), the signature of intermediate is validated using the public key of root (issuer of intermediate).
