gitproto: defer credential approval until response passes validation

Both credential-approval paths previously called CredentialHelper.Approve as soon as the retried request returned 2xx — before RequestInfoRefs validated the advertisement content-type and applied its size cap. A misleading 2xx (e.g. a captive-portal HTML body) would persist the credentials in the helper even though RequestInfoRefs still returned an error.

Unify around the existing pendingHelperCreds slot:

• tryHelperRetry no longer calls Approve directly on a 2xx retry. It sets c.Auth (so follow-ups on the same conn reuse the creds) and records the creds as pending, leaving approval to the caller. Rejection on 401/403/transport-error stays immediate — a definite auth failure is unambiguous.

• resolvePendingHelperCreds gains a success bool. Approve only fires when the operation actually succeeded (status 2xx and body validation passed); Reject still fires on 401/403; everything else leaves the creds pending and c.Auth in place.

• RequestInfoRefs now reads/validates first (httpError, content-type, redirect, size cap — extracted into readInfoRefsResponse) and only then settles helper state with success=(err==nil).

• PostRPCStreamBody settles with success=(httpError==nil), which is the full success signal for the POST path.

Adds TestRequestInfoRefs_OnUnauthorizedRetry2xxBadContentTypeDoesNotApprove to pin the new contract: a 2xx retry with a non-advertisement body must error out and must NOT call Approve (or Reject — it isn't an auth failure).

Addresses Cursor Bugbot review comment on PR #65: "Premature credential helper approve".