Fix: Subscriber handler errors silently swallowed causing potential data loss

[NitinKumar004]

Summary

• handleSubscription was logging handler errors but returning nil, which prevented the retry logic in startSubscriber from triggering on handler failures.
• Now the handler error is propagated back to startSubscriber, enabling its existing retry-with-backoff mechanism.
• Added unit tests for handler error propagation, successful handler, and subscribe error scenarios.

Fixes #3215

Test plan

• Added TestHandleSubscription_HandlerErrorReturned — verifies handler error is returned
• Added TestHandleSubscription_SuccessfulHandler — verifies nil on success
• Added TestHandleSubscription_SubscribeError — verifies subscribe error is returned
• Linter passes with 0 issues

[Umang01-hash]

• Previously:

{"level":"DEBUG","message":{"messageValue":"{\"orderId\":\"ORD-001\",...}","topic":"order-logs",...}}                                                                                           
  {"level":"INFO", "message":"handler received order #1: {OrderId:ORD-001 Status:FAILED}"}                                                                                                        
  {"level":"ERROR","message":"error in handler for topic order-logs: handler: downstream DB unavailable"}                                                                                         
                                               ↑ ONE error log, then immediately next message:                                                                                                    
  {"level":"DEBUG","message":{"messageValue":"{\"orderId\":\"ORD-BEFORE-FIX\",...}","topic":"order-logs",...}}                                                                                    
  {"level":"INFO", "message":"handler received order #2: {...}"}                                                                                                                                  
  {"level":"ERROR","message":"error in handler for topic order-logs: handler: downstream DB unavailable"}                                                                                         
                                               ↑ NO DELAY — tight loop!      

After fix (return err — PR change):

  {"level":"DEBUG","message":{"messageValue":"{\"orderId\":\"ORD-001\",...}","topic":"order-logs",...}}                                                                                           
  {"level":"INFO", "message":"handler received order #1: {OrderId:ORD-001 Status:FAILED}"}                                                                                                      
  {"level":"ERROR","message":"error in handler for topic order-logs: handler: downstream DB unavailable"}                                                                                         
  {"level":"ERROR","message":"error in subscription for topic order-logs: handler: downstream DB unavailable"}
                                 ↑ TWO error logs for the same error — from handleSubscription AND startSubscriber                                                                                
                                 ↑ Then 2-second delay before next message is attempted                                                                                                           
  {"level":"DEBUG","message":{"messageValue":"{\"orderId\":\"ORD-BEFORE-FIX\",...}","topic":"order-logs",...}}                                                                                    
                                               ↑ Next message 2 seconds later ✅ 

Every handler error fires both "error in handler for topic..." and "error in subscription for topic...". In a busy subscription loop under real failure conditions this doubles alert noise.

Maybe we can try a small fix: remove the Errorf on subscriber.go:70 and let startSubscriber's existing log (line 38) be the single error entry point.
That keeps error propagation clean and logs the error exactly once.