I think the answer is you don't implement AccessCheck() in an implementation class. Looking at some documentation examples, classes that extend %REST.impl don't extend %CSP.REST and the latter is where AccessCheck() exists and is called.
I think to get closer to what I want you'd forward your calls to the dispatch class to a lower level dispatch class which may call %CSP.REST.Page() (I haven't tested this yet). But my goal was implementation level access checks because we have row level security in a multi tenant database. Since often you'd find a object ID in a URL (/csp/testApp/coffeePots/:coffeePotId) and, in my little example here, coffeePotId is most easily accessible in the method implementation itself, the only way to check the access to that ID at a higher level would be to do some tricky URL parsing that the %CSP.REST methods already do so well behind the scenes.
My solution was to create a XData block of all the mappings from objectClass -> HTTP Method -> associatedPermission (e.g. CoffeePots -> POST -> Can create coffee pot) and then use that in a generic method that can be called in each implementation to check permissions.
On another note, you don't want me writing a best REST API practices article for the next ISC article contest, lol.
The closest I've gotten here is to use OnPreDispatch() to hack the flow and call the ImplementationClass.Page() method but this opens a whole can of worms.
I'm not sure this is the answer you're looking for, but I would loop through the result set and store the data in a local array and then loop through the array and output the data with the calculated column set as you wish. The array would allow you to loop through each ID to find the latest to mark as new. This is an ObjectScript approach along with SQL. I wonder if you could just re-save the data back to the table once calculated so you can still project it as needed to other systems.