Malformed --tls-crl-file causes a nil-pointer panic at startup instead of a config error

[graysoncooper]

SetupCrls logs but does not act on a CRL parse failure, then immediately dereferences the (nil) parse result:

smokescreen/pkg/smokescreen/config.go

Lines 485 to 493 in f03c477

	certList, err := x509.ParseCRL(crlBytes)
	if err != nil {
	log.Printf("Failed to parse CRL in '%s': %#v\n", crlFile, err)
	}
	// find the X509v3 Authority Key Identifier in the extensions (2.5.29.35)
	crlIssuerId := ""
	extensionOid := []int{2, 5, 29, 35}
	for _, v := range certList.TBSCertList.Extensions {

When x509.ParseCRL fails, certList is nil and the very next line ranges over certList.TBSCertList.Extensions, panicking.

Reproduction

1. Start smokescreen with a valid TLS server bundle and client CA.
2. Pass a file of malformed CRL bytes via --tls-crl-file.
3. Startup logs "Failed to parse CRL" and then panics on a nil dereference rather than exiting with a clear configuration error.

Effect
A bad CRL file crashes the proxy on boot instead of being rejected cleanly; the proxy stays down until the file is corrected.

Suggested fix
Return the parse error (or skip the file under an explicit non-fatal policy) immediately after ParseCRL fails, before touching any certList field.

Found while testing Ito, an automated code-review tool, against recently-merged PRs. It's free for open source. Sharing this because it looked like a real bug worth fixing, not to sell anything: https://app.ito.ai/share/4de55e86-1d2e-46f0-aa54-14b421fd9eb7?tab=details