fix(im): recover channels after leader lock loss

[March-77]

Description

Restore an in-process recovery path when a WebSocket or long-poll IM runtime loses its Redis leader lease.

The renewal loop now stops the adapter and schedules the channel through the existing leader takeover loop. That loop already re-reads the durable channel row before reconnecting, preserving delete/disable/config freshness checks and the per-channel retry deduplication guard.

Root cause

wsLeaderRenewLoop called StopChannel and returned when renewal failed or ownership was lost. Only startup-time acquisition failures entered wsLeaderRetryLoop, so an enabled Feishu WebSocket channel could remain inactive until the app restarted.

Impact

Transient Redis renewal failures or lease replacement no longer leave enabled channels permanently stopped. Duplicate loss handling remains idempotent, and a channel deleted or disabled while waiting is not resurrected.

Testing

• go test ./internal/im -run 'TestLeadershipLossStopsAdapterAndSchedulesRecovery|TestLeaderElectionFailsClosedWhenRedisUnavailable' -count=1
• git diff --check

Fixes #2344