Normally, the output of the hwclock command is in the local timezone... and the timezone definition includes daylight saving time transitions.
The internal clock of the Linux kernel (as with most unix-like systems) always runs internally in UTC time: whenever a local time is needed, the timezone definition is used to convert the internal UTC representation to the local time. When a DST transition occurs, this means the "local time" appears to jump forward or backward as appropriate. At the same time, the timezone offset reported along with the local time value also changes: usually a DST prefix is added or removed, or if the timezone is expressed as +/- offset to UTC time, that offset value will also automatically change at DST transition.
If you had requested hwclock to show its output in UTC timezone (i.e. TZ=UTC hwclock) then you would have seen the time tick forward as usual, with nothing special happening at the time of DST transition.
So the real explanation is: no special command was executed, instead an old UTC offset value specified in /etc/localtime expired and a new offset defined for a new period of time took effect. You can see all the past and future DST transition times with zdump -v /etc/localtime if you wish. If there are other non-DST changes in the timekeeping in the history of your local timezone, those should be covered too.
But to your actual question, the only reliable way to find out who ran a particular command would be the audit subsystem (auditd and the related tools), which will produce logs in /var/log/audit when configured to do so (or to a custom directory if desired). But it will only log things from the point it has been started: it won't help with events in the past if it is not already configured with suitable logging.