fix: allow rediss:// TLS endpoint with separately-configured password

[jalee-cpu]

Problem

When using a TLS Redis endpoint (rediss://host:6379) without an embedded password, redis.ParseURL succeeds but returns options.Password = "". The current check in getRedisClientOptions then fires errPasswordsDoNotMatch if ATHENS_REDIS_PASSWORD is also set — even though there is no actual conflict, the URL simply has no password component.

// Current (broken for rediss:// + separate password)
if password != "" && options.Password != password {
    return nil, errPasswordsDoNotMatch  // "" != "realpassword" → crash
}

This makes it impossible to use the common Kubernetes deployment pattern of:

• ATHENS_REDIS_ENDPOINT=rediss://host:6379 (TLS scheme, no password embedded in URL)
• ATHENS_REDIS_PASSWORD=<secret> (injected separately via a k8s Secret)

ElastiCache and other managed Redis services commonly require both TLS (rediss://) and an auth token, and best practice is to inject credentials via secrets rather than embedding them in the endpoint URL.

Fix

Only error when the URL contains a password that disagrees with the separately-configured password. When the URL has no embedded password but ATHENS_REDIS_PASSWORD is set, apply the password to options so it is used for AUTH.

// Fixed
if options.Password != "" && password != "" && options.Password != password {
    return nil, errPasswordsDoNotMatch
}
if options.Password == "" && password != "" {
    options.Password = password
}

Test

Added a test case for rediss://host:6379 + separate password to Test_getRedisClientOptions. All existing tests continue to pass.

[Ullaakut]

LGTM

[jalee-cpu]

LGTM

Thank you for the approval! What are the steps to merge?