fix: stop double-reporting errors via Log::error in handleException

[JasonHolderness-bl]

Summary

Removes the Log::error(..., ['exception' => \$e]) call inside LeverClient::handleException(). The thrown LeverApiException already carries statusCode, responseBody, and the original Guzzle exception as \$previous — everything a caller needs to log or classify the error. Logging is now the caller's responsibility.

The wrapped exception message also now includes the endpoint ("HTTP $method $endpoint failed: ...") so callers don't need to inspect the previous chain to identify the failing call.

Why this matters

Downstream Laravel apps using Bugsnag (or any monolog handler that promotes the exception context to a separate error) were getting two reports per failed Lever request — once from this internal Log::error (grouped as GuzzleHttp\Exception\ClientException) and again when the caller's queue worker / exception reporter handled the propagated LeverApiException.

In one observed production case in the Spot project, this produced 120 + 104 = 224 redundant Bugsnag events for the same handful of permanently-failing job sync attempts.

Notes

• Backwards compatible at the type level: LeverApiException extends RuntimeException, so any caller using catch (RuntimeException $e) is unaffected.
• The exception message changed from "Error executing HTTP $method. Please check the logs for more details." to "HTTP $method $endpoint failed: <original message>". Callers matching on message text would need to update — none in the test suite do.
• Removed the now-unused use Illuminate\Support\Facades\Log; import.

Test plan

• Existing tests pass (OpportunitiesTest::fail_to_create_opportunity_when_no_perform_as_parameter_included still passes via RuntimeException::class parent match)
• OpportunitiesTest::client_error_exposes_status_and_response_body still validates statusCode/responseBody/previous chain
• Tag v1.0.11 after merge

🤖 Generated with Claude Code