transaction malleability – How and when were high-s signatures made non-standard?

The requirement for transactions to only have low-s signatures is a standardness rule. Standardness is enforced at the mempool policy level and is not a protocol rule. Although the mempool behavior of Bitcoin Core has broad impact on the viability of transactions on the network, since mempool policy and standardness are local choices of Bitcoin Core, they have not always been documented in BIPs.

As mentioned, it was proposed to forbid high-s signatures at the protocol level in BIP62 with the original goal to resolve malleability concerns pertaining to scripts. BIP62 was withdrawn because just script rules were not enough to resolve transaction malleability concerns.

Signatures were later canonicalized in BIP66, and third-party malleability concerns regarding scripts were entirely resolved with BIP141. High-s signatures are still permitted: even for segwit outputs they are only non-standard, so while the txid is no longer influenced by signature data, the wtxid still is, and is still vulnerable to third-party malleability.

Returning to the main question, it turns out that the Bitcoin 0.9.0 release both started considering high-s signatures non-standard and only creating low-s signatures.

_{Note that third-party transaction malleability generally only concerns ECDSA signatures, Schnorr signatures are inherently non-malleable.}