defer probe credential approval to the real operation

The previous probe logic ran a second authenticated GET /<service> and approved the credentials whenever that response wasn't 401/403. But many servers return 405 to GET /git-receive-pack without ever validating the Authorization header — so a 405 with attached credentials proves nothing. Approving in that case was a false positive: stale helper creds got blessed, c.Auth was set, and the streaming POST that followed skipped the helper retry path. The push then failed with no way to recover the bad helper state.

Fix: the probe is now strictly anonymous. Its only job is to detect whether the server requires auth here (the 401 signal). If it does, the helper-supplied credentials are attached to c.Auth tentatively and recorded as pendingHelperCreds. The next real operation (PostRPCStreamBody or RequestInfoRefs) calls resolvePendingHelperCreds on its response: Approve on 2xx, Reject + clear c.Auth on 401/403, no-op otherwise. So helper state only changes when the real operation provides a definitive signal — which is what git itself does.

Six new/updated tests:

• TentativelyAttachesHelperCredsOnAnonymous401: c.Auth set, no Approve
• 405ProbeWithCredsDoesNotPoisonHelper: explicit regression for the bug
• RealPostApprovesTentativeCreds: 2xx on the real POST → Approve
• RealPostRejectsTentativeCreds: 401 on the real POST → Reject + clear
• NoHelperIsNoOp, AnonymousServiceLeavesAuthNil: existing semantics preserved