reverted partial client side back button logic, but also now tested / validated if somehow we are in a flat view and ask for entries and dont get all of them back, or we are in folder view and we try to go into a folder or back up a folder and we get no data as someone deleted it since we made the view, so then show appropriate client-side errors

TODO

@@ -1,13 +1,13 @@
 ###
-# 
+#
+#
 # consider how to better version jscript - across all html files, consistently
 #   mtime, didnt work anyway, my phone still wont pick up the change, it was adding any ?v= changed this (once)
 #
 # 5 think I killed pa_job_manager without passing an eid to a transform job, shouldn't crash
 #    SHOULD JUST get AI to help clean-up and write defensive code here...
 #
-# could cache getPage into document.page[x], then check if it exists, if so, don't go back to server for all the data, page[x], would need -> entrylist, pagelist, entries AND we need to consider if cache can be invalidated, then how do I know / do I care... I THINK not, as the data is all self-contained, only will go pear shaped if we get a new page, and then it shoudl get a new set of entry ids -- now, if they are not fully contained in entrylist, we have a problem -- IS that the condition I should check?
-## the above needs thought, even without cache, I go back a dir, and its now deleted, or I go forward/back a page and the entry ids have changed is there any way this can bite me... I think only if flat view the next/prev page of ids has no content / unexpected content?   get_dir_eids is a new hit each time, so it could fail for deleted folders, etc.
+# could cache getPage into document.page[x], then check if it exists, if so, don't go back to server for all the data, page[x], can just store document.entries
 ###
 
 ### major fix - go to everywhere I call GetEntries(), and redo the logic totally...