fix: reject out-of-range resultCode in GetLDAPError

[netliomax25-code]

1. GetLDAPError narrows the server's resultCode from int64 to uint16 before testing it for success, so a code whose low 16 bits are zero (65536, 131072, or a negative multiple) is read as 0 and the function returns nil.
2. It is the single place where Bind, Add, Del, Modify, ModifyDN, Compare, Extended and Search decide whether a reply failed, so such a reply reaches the caller as a successful operation, and a value like 65586 is aliased onto 50 (insufficientAccessRights), which also sends IsErrorWithCode down the wrong branch.
3. parseLDAPResult narrows the same field into SearchResult.ResultCode and DigestMD5Bind compares the narrowed value with 14, so 65550 is taken there for saslBindInProgress.
4. Added packetResultCode beside the other guarded leaf conversions and used it at those three sites, so an out-of-range code takes the existing "invalid result code in packet" path; RFC 4511 section 4.1.9 asks clients to cope with unrecognized codes and those are untouched, since the check only rejects what the uint16 in Error.ResultCode cannot represent.

Validation: a BindResponse carrying resultCode 65536 over the in-package fake connection makes Conn.Bind return nil on master and the decode error after the change, and the new cases in error_test.go fail on master. go vet, go build and go test -cover -race -count=1 ./... pass locally against the make local-server directory.