Both of those assertions are known to be related to hardware failures. In fact, the 200505 checksum assertion was specifically added to detect media failures after pages have been written to the media. Further, the 101412 assertion is one of the top 1 or 2 assertions I usually see when there has been a media failure (ie corrupt database); when checksums are not in use of course.
So hardware failures would be a leading candidate cause here. If you are seeing the same page numbers come up than I would expect a bad write to media or a bad spot on the media is involved.
There is always a possibility that htis is something different but I would start looking at the more probable media aspects of these.
Also, once a bad write has happen every time you cycle around to the same broken page you will get an assertion and that may explain the frequency of the occurrance.
{How did you determine the page in question is in the Temporary dbspace?
If you have been working with Product Support on this issue I would urge you
to continue to do so; so we can investigate this more deeply.}
IFF it is always the temporary file and media that is involved, then, I would suggest seeing if setting
the %SATMP% or %TEMP% or %TMP% to force the server to run on another device and check to see if that changes the behaviour any. If it does then the media itself is truly questionable and where you should focus most of your efforts.
If there is corruption in the main dbspaces then you probably should validate the database and possibly rebuild it to see if you have captured bad pages permanently inside the permanent database files. Maybe switching to a different machine is possible, and if it is that could help to isolate the failing component.