In re file save/open, my recollection of the ToolKit documentation is that there's pretty good support for serialisation of the object state of your program, and that the creation of a stationery pad is also handled automatically by the Workshop program that installs a tool onto your Office System desktop. See
Segment 2 of Lisa ToolKit Self-Paced Training, "What is a Document?", especially this quote on PDF page 23:
The end user can put a document away using a command in the File/Print Menu. The document heap (holding the view, the panel, the window, and whatever else had a hand in managing your document's data) is copied into a file. Then the file gets closed. Finally, the window frame goes away, leaving an icon as the sole reminder of the document.
What's not clear in this quote is that the ToolKit does this all for you --- you don't have to write code that does it yourself. So as far as #4 goes, I think you get all that for free if you use the ToolKit. #1 is also the case as I understand it, though ToolKit apps make use of a thin layer on top of QuickDraw that uses 32-bit X and Y coordinates for drawing instead of QuickDraw's 16-bit values. For everything else: a journey through creating the world's first substantial new ToolKit application in decades (so far as I know) awaits you! Good luck!
(I know that must sound sarcastic, but it would be incredible if you or anyone else made a new ToolKit app. Someday I'll get around to trying it myself...)
ETA: Having neither attempted to author a ToolKit program nor having examined the MacPaint code, I'd be surprised if there was an easy way to get the MacPaint code to run on the ToolKit. There may be a different way to write code for the Office System that's a little easier --- maybe QuickPort would be a better choice?