ecdsa – Effect of byte length of r and s on DER encoded signatures

As described in this answer to What is the maximum size of a DER-encoded ECDSA signature? The DER encoded signature for a specific ECDSA signature (r, s) has the following format:

0x30 = 1 byte constructed sequence type
L = 1 byte length of the following bytes (excluding SIGHASH byte)
0x02 = 1 byte primitive integer type
LR = 1 byte length of integer r
R = integer r in big endian
0x02 = 1 byte primitive integer type
LS = 1 byte length of integer s
S = integer s in big endian
SIGHASH = 1 byte

Here, if the most significant bit of r is 1, byte 0x00 is added before r, and the same goes for s.

But what if the byte length of r is less than 32?

For example, let’s say you have the following case:

r = 0x83e1ed5c6298a2dfb3e98f2d8963575487c888ac02483045022100ec6ab2

It is 30 bytes.

we are

(1) Since the highest bit (i.e. bit 239) is 1, add 0x00 to it as follows:

0x0083e1ed5c6298a2dfb3e98f2d8963575487c888ac02483045022100ec6ab2

In the R field above, or:

(2) Write in full 32-byte format.

0x000083e1ed5c6298a2dfb3e98f2d8963575487c888ac02483045022100ec6ab2

Therefore, do not prepend 0x00 because the highest bit (i.e. bit 255) is 0. So, type:

0x000083e1ed5c6298a2dfb3e98f2d8963575487c888ac02483045022100ec6ab2

In the R field above?

Can anyone point to an example of a blockchain transaction that shows how these short r, s values ​​are handled?

Is there any possibility of malleability here? Assuming (r, s) is a valid signature, are both options (1) and (2) allowed in Bitcoin Core?

Or do I always remove leading zero bytes from r and s before considering whether the highest bit is 1 (0 is not an acceptable value for r or s)?