newEncodeError adds potentially sensitive data to error messages.

```
func newEncodeError(value any, m *Map, oid uint32, formatCode int16, err error) error {
var format string
switch formatCode {
case TextFormatCode:
format = "text"
case BinaryFormatCode:
format = "binary"
default:
format = fmt.Sprintf("unknown (%d)", formatCode)
}

var dataTypeName string
if t, ok := m.TypeForOID(oid); ok {
dataTypeName = t.Name
} else {
dataTypeName = "unknown type"
}

return fmt.Errorf("unable to encode %#v into %s format for %s (OID %d): %w", value, format, dataTypeName, oid, err)
}
```
The last line is what I'm referencing. I moved away from `sqlx` because it does this and a bug printed email signup codes to some error logs. I know this is trying to be helpful but the error has no type so you can't check for it to filter it out, and normal error wrapping means it will almost certainly end up in the logs -- why else have an error if not to print it. Most people wouldn't expect a library to print your data like this.

https://github.com/jackc/pgx/blob/61d3c965ad442cc14d6b0e39e0ab3821f3684c03/pgtype/pgtype.go#L1936

Read pgtype/pgtype.go at newEncodeError and trace its callers to see how the error is surfaced. Done means encoding errors no longer include potentially sensitive input data, while retaining the existing format, type, OID, and wrapped-error context.

Written by the indexing model from the issue text.