fix(skstore): purge DeletedDir tombstones at end of update transaction

[zaccharyfavere]

fix(skstore): purge DeletedDir tombstones at the start of the next update

DeletedDir entries were created in Dirs.state by removeDir() to mark
directories as deleted, but were never cleaned up. They accumulated
indefinitely, causing a persistent memory leak proportional to the number
of subdirectories created and destroyed over time.

The fix adds a purgeDeletedDirs() method on the Context class and calls it
at the start of each update cycle, right after the working context is
cloned and before the cycle's work runs. A tombstone therefore survives
the full cycle that created it (including sync and notifications) and is
only collected once the next cycle begins, which is the point at which it
is no longer needed.

[CLAassistant]

All committers have signed the CLA.

[mbouaziz]

Hi, thanks for your contribution!
Sorry, CI failures might be because I switched jobs to use gen 2 circle ci instances but they may be counting memory differently

[zaccharyfavere]

Hi, alright thanks for your return !

[mbouaziz]

Sorry, still fixing the CI...
Very bad timing for a broken CI, we haven't had any external contribution for months 😆

[zaccharyfavere]

No worries, I just re pushed because I realised there was a format error still in my code. That should be fixed now since it made one of the CI pass

[mbouaziz]

I think the CI is back to normal, I've rebased your commit to check

[mbouaziz]

getDirsChangesAfter(tick) relies on DeletedDir tombstones to report deletions to downstream consumers after updateWithStatus returns. Purging them here means subsequent calls (e.g. importNext/import in the synchronizer's exportToRoot path, notifyAll, CHANGED_DIRS computation in resolveContext) won't see the deletion.

Concretely, a DROP TABLE/DELETE followed by update() would purge the tombstone before exportToRoot -> importNext scans for DeletedDir, so the drop never propagates to root.

I understand the memory leak but a safe purge needs to be bounded by the slowest consumer of the change history, e.g. track the min tick across active synchronizers/subscribers and only drop tombstones below it, or do the compaction at a synchronization boundary that's provably past the last reader.