Sanitize server-authored text and derive the TLS-verification state

Two hardening items from the security review.

Server-authored text reached terminals, logs and --json output unfiltered, on five paths: sideband progress, up to 64 KiB of HTTP error body, receive-pack "ng" rejection reasons, diagnostic response headers, and ssh's relayed "remote:" output. A hostile remote could embed an escape sequence to redraw the line its own message was printed on — a rejected push made to read like a successful one — or smuggle control characters into whatever ingests the JSON.

All five now go through internal/sanitize, which drops everything below 0x20 plus DEL while keeping tab, newline and carriage return: git's in-place progress output depends on them, and the "source:"/"target:" line prefix already bounds how much a '\r' alone can hide. The single-byte C1 introducers are deliberately out of scope — in a UTF-8 stream they are not valid standalone bytes and terminals in UTF-8 mode do not act on them. Rejection classification still runs on the raw status, so filtering cannot change whether a rejection is treated as a concurrent move.

The streaming filter reports the byte count it was given rather than the smaller number written, so a caller checking n against len(p) does not see a short write for text that was intentionally dropped.

Separately, HTTPConn.InsecureSkipTLSVerify was documented as a field callers must set to match the client they pass in, and the cross-host credential guard reads it. A caller who disabled verification on their transport but forgot the field silently lost that protection — the wrong direction for a security check to fail. The transport is now inspected directly, following Unwrap through wrappers so an instrumentation layer cannot hide the setting; the syncer's counting round-tripper gained an Unwrap for exactly that. The walk is bounded, so a cyclic chain terminates rather than hanging. The explicit field still forces the guard on, for transports that cannot be inspected.