tl;dr: Take a look at your system logs, or use something like bootlogd, this should show you where the slow down is occurring. My bet would be that it is not fsck.
Firstly, fsck can run whenever, it doesn't have to run at boot. What you're probably referring to is that it can only run on an unmounted filesystem, and since / and other filesystems are mounted when the system is fully operational, that is the only possible time to run it on those filesystems.
fsck should not take hours to complete if it is merely doing a regular check, unless it actually finds inconsistencies in the filesystem and has to fix them (but even then, an hour sounds highly unlikely, even on a large filesystem with numerous inconsistencies). Take a look at your system logs, or use something like bootlogd, this should show you where the slow down is occurring. My bet would be that it is not fsck.
Filesystems can develop inconsistencies without any noticeable side effects, that's the purpose of the regular fsck checks regardless of whether the filesystem is marked dirty.
You cannot unmount your root filesystem whilst the system is running, as it will be in use, therefore you cannot run fsck on it, so there is no way to properly run a cron job to do it. It would be possible to force a fsck on a reboot on certain dates, and then reboot, but I don't really see the point. I don't really understand what you mean by being "out of sync".
After a crash, fsck will run on any dirty filesystems, that is, filesystems that were not cleanly unmounted. If your computer was to crash during normal operation, therefore, yes, fsck would run. If your computer crashed at the very final stage of shutdown, probably not, as the filesystems would not have been compromised.
