fix: Check the token response body read error where the body is load-bearing

[keelerm84]

Summary

authorizeSalesforce captured the error from reading the token response body but did
not inspect it until after both status branches had already used those bytes -- the
error was passed to log.Print in each branch, which is how it surfaced without ever
being handled.

The naive fix, hoisting one check above the status branches, would be a regression. A
401 or 403 on a body read failure currently returns a permanent error, and hoisting
makes it non-permanent, leaving the daemon retrying forever against a credential
Salesforce has already rejected.

So the read error is judged per branch, according to whether the branch depends on
the bytes. The status line arrives ahead of the body, so net/http returns a
complete StatusCode whether or not the read finished; a truncated body casts no
doubt on the status.

• 401 / 403 -- the status alone proves the credential was refused, and the body
  only feeds the log line. Stays permanent.
• Other non-200 -- the body becomes the error message, so the read error is
  reported here.
• 200 -- the body is the token document, so the read error is returned before
  json.Unmarshal.

Two further fixes in the same lines. The generic non-200 branch returned
errors.New(string(errorBody)), which on an empty body is a non-nil error that
prints nothing -- a bodyless 503 from a load balancer in front of Salesforce is
ordinary, and the existing 503 is retried test case passed only because it asserted
err != nil. The message now always carries the status code, on both the read-failure
path and the normal one. The local was also renamed to readErr, since which error is
in hand is the whole bug.

The new tests fix one grant, since every line under test runs after client.Do and
existing coverage already establishes that response handling is grant-independent.
They were verified to discriminate in both directions: against the original code, and
against the naive hoist, which fails the 401 and 403 rows on the permanent flag.

---

Note

Overview
authorizeSalesforce now treats a truncated token response body differently depending on HTTP status, instead of only logging the read error while still using partial bytes.

For 401/403, the failure stays permanent and returns Salesforce Unauthorized even when the body read fails—so bad credentials are not retried forever. For other non-200 responses, a body read failure is returned (wrapped with the status code); otherwise the error message always includes the status and body text, fixing empty errors on bodyless responses like 503. For 200, a partial body read is returned before JSON parsing so a truncated token is never stored.

Adds authorize_readerr_test.go with a truncating mock token server and tests that pin the permanent vs retry behavior and non-empty transient error messages (including guarding against a naive “check readErr first” regression).

^{Reviewed by Cursor Bugbot for commit 099edf9. Bugbot is set up for automated code reviews on this repo. Configure here.}