While Neo4j does use the pagecache for an in-memory graph, it writes out changes to the graph to transaction logs on disk as well as the pagecache. When a transaction is recorded in the transaction log, it is considered committed. These are durable, and will survive unexpected shutdowns of Neo4j or the server itself.
At intervals, checkpoint operations flush changes from the transaction logs to the store files themselves, and performs any rotation and pruning of the transaction logs needed.
During startup, Neo4j checks for the occurrence of the last checkpoint in the transaction logs, and replays all subsequent transactions to the pagecache, this is part of what's going on when you see Neo4j going through a recovery process on startup.
When pages are evicted from the pagecache that are dirty, they are flushed to the store files. That way even when performing recovery from the tx logs, the pagecache doesn't need to be large enough to contain all subsequent changes.
For write transactions, as the transaction is processed the heap is used to contain transitory state as well as the final transactional changes resulting from the query. The commit process writes these to tx logs and pagecache.
As you said, Neo4j guarantees read-committed isolation. When used in a cluster, it promises causal consistency (if you are using bookmarks or between transactions within the same session, otherwise eventual consistency as far as reading your own writes. If only interacting with the leader, then it's read-committed isolation just as it is in a single instance).
