#34980 include exception in addBinaries

[dsilvam]

Summary

• Pass the caught exception to Logger.warn() in DefaultTransformStrategy#addBinaries so the full stack trace is included in the warning log, not just the message string.

Problem

When a binary field fails to be retrieved during contentlet transformation, the warning log only captured e.getMessage() as a string argument. This meant the stack trace was silently dropped, making it very difficult to diagnose the root cause of binary retrieval failures.

Solution

Pass e as the third argument to Logger.warn(), which triggers the overload that logs both the message and the full exception stack trace.

// Before
Logger.warn(this,
    String.format("An error occurred when retrieving the Binary file from field"
        + " '%s' in Contentlet with ID '%s': %s", field.variable(),
        contentlet.getIdentifier(), e.getMessage()));

// After
Logger.warn(this,
    String.format("An error occurred when retrieving the Binary file from field"
        + " '%s' in Contentlet with ID '%s': %s", field.variable(),
        contentlet.getIdentifier(), e.getMessage()), e);

Test plan

• Trigger a binary field retrieval failure and confirm the full stack trace appears in the logs

This PR fixes: #34980

[claude]

Claude finished @dsilvam's task in 46s —— View job

---

Rollback Safety Analysis

• Reading rollback-unsafe categories reference
• Getting PR diff
• Analyzing changes against unsafe categories
• Applied label: AI: Safe To Rollback

Result: Safe to Rollback ✅

The single-line change adds the exception object e as a third argument to Logger.warn() in DefaultTransformStrategy.java:274, so that the full stack trace is included in the warning log (instead of just e.getMessage()).

This is a pure logging improvement with no impact on:

• Database schema or data
• Elasticsearch mappings
• API contracts
• OSGi interfaces
• Storage providers
• Push publishing bundle format

None of the rollback-unsafe categories (C-1 through M-4) apply.