Summary

• getMaster(), getSlaves(), and updateSentinels() only catch ConnectionException when connecting to Sentinel nodes. StreamInitException (thrown by stream_socket_client() failures in StreamFactory) extends PredisException directly — not ConnectionException — so it propagates uncaught, preventing fallback to the next Sentinel node.
• This causes complete application failure when any single Sentinel is unreachable, even if other Sentinels are healthy. Every PHP worker gets stuck in the retryCommandOnFailure() loop retrying the same dead Sentinel.
• Adds StreamInitException to the catch clause via union type in all three methods. This is more precise than catching PredisException or Throwable, which would also swallow ServerException (e.g. ERR No such master with that name) and mask configuration errors.

Related: #1577 applied a similar fix to retryCommandOnFailure() but missed these three sentinel discovery methods.

Exception hierarchy context

PredisException
  ├── CommunicationException
  │     └── ConnectionException      ← caught before this fix
  ├── StreamInitException            ← NOT caught (thrown by stream_socket_client failure)
  └── ServerException                ← should NOT be caught (config/protocol errors)

How to reproduce

1. Configure Predis with 3 Sentinel nodes
2. Make one Sentinel unreachable at the network level (e.g. blackholed IP, NIC disconnect — not a clean process shutdown)
3. stream_socket_client() to the dead Sentinel throws StreamInitException
4. getMaster() / getSlaves() / updateSentinels() don't catch it → no fallback to the next Sentinel
5. retryCommandOnFailure() catches it, but retries hit the same dead Sentinel every time

Test plan

• Existing Sentinel test suite passes
• Verify StreamInitException during sentinel discovery triggers fallback to next sentinel
• Verify ServerException (e.g. wrong service name) still propagates without retry