read DNS RDLENGTH as an unsigned 16-bit value

[basavaraj-sm05]

readResourceRecord pulls the record data length out of the RDLENGTH field, which RFC 1035 defines as an unsigned 16-bit integer, but it decodes that field with readShort().toLong(), so any length with the high bit set comes back negative. Every other 16-bit field in this reader already goes through toUShort(), so this one is the odd one out. For an A or AAAA record the wrong sign is caught by the exact-length check, but for a record type we don't decode the code falls into skip(recordDataLength), and okio's skip treats a negative count as a no-op rather than an error. That means a record legitimately carrying 32768 or more bytes never gets consumed, the reader stays parked in the middle of the message, and the leftover bytes either trip the trailing-data check or get read as the next record. I hit it while feeding the reader a response with a large unknown record sitting in front of an A record. Decoding the field as unsigned, the same way the counts and the HTTPS parameter lengths already are, keeps the stream in sync, and I added a regression test that reads a message with an oversized unsupported record.