Add SSRF protection to read_file URL fetches (#587, #560)

When following redirects, the code calls assertUrlIsFetchable(nextUrl) which performs a DNS lookup on the redirect target's hostname. If the redirect target is a hostname that resolves to a mix of public and private IPs, the guard correctly blocks it. However, the DNS resolution itself has already occurred, potentially leaking the internal hostname to the DNS resolver configured on the host. This is a minor information disclosure vector, but since the DNS query is made before the IP check, an attacker could use a redirect to trigger DNS lookups for internal hostnames. The severity is medium because it requires a malicious or compromised redirect target and a DNS resolver that logs or monitors queries.

The redirect URL is constructed using new URL(location, currentUrl).toString(). If the location header contains a protocol-relative URL (e.g., //internal.example.com/admin), the resulting URL will inherit the scheme from currentUrl but use the new hostname. This is standard URL resolution behavior, but it means the hostname in the location header is not directly validated as a hostname—only the resolved IP addresses are checked. If internal.example.com resolves to a public IP due to split-horizon DNS or a misconfiguration, the guard would pass, potentially allowing access to an internal service. This is a low-severity edge case because it requires a specific DNS setup and a redirect to a protocol-relative URL.

The PDF handling branch now uses currentUrl (the final validated URL after redirects) instead of the original url. While this is correct for SSRF protection, the isPdf check still uses currentUrl.toLowerCase().endsWith('.pdf') as a fallback. If the final URL after redirects does not end in .pdf but the content is actually a PDF, the isPdfFile(contentType) check should catch it. However, if the Content-Type header is missing or incorrect, and the URL does not end in .pdf, the file will be treated as non-PDF, potentially bypassing the PDF parsing logic. This is a low-severity edge case because it requires a misconfigured server and a redirect chain that changes the URL extension.