As @avivey suggests, the remaining cache can be cleared with:

$ ./bin/cache purge --caches user

In some other similar cases (where data is deleted manually from the CLI instead of via UI tools), you may need to purge other caches using this tool, most commonly the general or remarkup cache. It is broadly safe to just purge everything with bin/cache purge --all. At least today, all the caches this command purges are readthrough caches, so the worst outcome from purging too much stuff is a small performance cost while they rebuild.

(Also, you normally should not need to use sudo to execute bin/* commands, although it's possible that this is required in your environment. There isn't too much downside to using sudo, but if we have some terrible bug in some future version of Phabricator it might do a little more damage with sudo than without.)

Eventually, we should probably have real tools for quarantining, but (as elsewhere) this is very difficult to prioritize because it only affects open source installs.

In this particular case, the ideal flow would probably allow the edit itself to be quarantined into an approval queue. This implies a two-phase commit (user proposes a change, administrators approve it) for all edits against all objects. This is conceptually an enormous undertaking, although we could conceivably hold/serialize/store transactions instead of changing objects to exist in multiple states. See also T11440.