fix(conn): guard against nil MaintNotificationsConfig in initConn

[veeceey]

Summary

• Fix nil pointer dereference in initConn when MaintNotificationsConfig is nil
• Add regression test that verifies the fix against the exact panic scenario

Problem

In baseClient.initConn(), line 540 accessed MaintNotificationsConfig.EndpointType unconditionally, even though line 538 correctly nil-checked MaintNotificationsConfig via short-circuit evaluation:

// Line 538: correctly checks for nil
maintNotifEnabled := c.opt.MaintNotificationsConfig != nil && c.opt.MaintNotificationsConfig.Mode != maintnotifications.ModeDisabled
protocol := c.opt.Protocol
// Line 540: BYPASSES the nil check — panics when MaintNotificationsConfig is nil
endpointType := c.opt.MaintNotificationsConfig.EndpointType

When MaintNotificationsConfig is nil, this causes:

1. A nil pointer dereference panic
2. optLock.RLock() is left held (never reaches RUnlock()), causing a deadlock on the next call

Fix

Move the EndpointType access inside a nil guard, consistent with the existing nil check on the Mode field:

var endpointType maintnotifications.EndpointType
if c.opt.MaintNotificationsConfig != nil {
    endpointType = c.opt.MaintNotificationsConfig.EndpointType
}

Test plan

• Added TestInitConnNilMaintNotificationsConfig regression test
• Verified test fails (catches panic) without the fix
• Verified test passes with the fix
• go vet ./... passes
• go build ./... passes
• All existing unit tests pass (only TestGinkgoSuite fails, which requires a running Redis server)

Fixes #3675

🤖 Generated with Claude Code

[ndyakov]

Thank you @veeceey, I think we can directly use if maintNotifEnabled since it reads better, don't you think?

[veeceey]

Good point, that does read better. Updated to use if maintNotifEnabled -- since it already implies the config is non-nil, the guard is redundant. And endpointType is only consumed inside the if maintNotifEnabled block below anyway, so the semantics stay the same.

[ndyakov]

Thank you @veeceey!