That sounds like design discussions best had in the issue/ticket itself, before you even start writing code. Then the commit message references the ticket and has a brief summary of the changes.
Writing and reading paragraphs of design discussion in a commit message is not something that seems common.
Not really about design, but technical reasons why this solution came to be when it’s not that obvious. It’s not often needed. And when it does, it usually fits in a short paragraph.
Ticket systems are quite ephemeral. I still have access to commit messages from the 90s (and I didn't work on the software at the time). I haven't been able to track the contents of the gnats bug tracker from those days.
And of course tickets can be private, so even if the data survived migration, you may not have access to it (principle of least privilege and all that).