This is brilliant — using ESLint to catch cache invalidation issues at dev time instead of discovering them in production. The custom rule approach is much better than relying on code review for this.
I ran into a similar pattern building a GraphQL API layer for an automation system. Cache misses after mutations were our #1 source of bugs until we started enforcing id field inclusion in mutation responses. Your ESLint approach would have caught those instantly.
Curious: did you consider extending this to also detect cases where nested entity references might cause stale cache? e.g., if a Post mutation returns author { id } but not the updated author.name, Stellate would still serve stale author data on the next read.