fix: verify the digest-md5 rspauth value in DigestMD5Bind

[netliomax25-code]

1. DigestMD5Bind accepts the final bind response on resultCode alone; the rspauth value in serverSaslCreds is never read, so a server (or an active attacker on a non-TLS connection) can answer the digest-response with success and be treated as authenticated without knowing the password.
2. The client now derives the expected response-auth (RFC 2831 section 2.1.3) alongside the digest-response and fails the bind when the success response omits rspauth or carries a different value, which matches how Cyrus SASL and the JDK DIGEST-MD5 client behave; conforming servers always send this value, so valid binds are unchanged.

computeRspauth is verified against the worked example in RFC 2831 section 4, and a scripted-server regression test covers the valid, missing, and mismatched rspauth cases under go test -race.