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

[zaccharyfavere]

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 Dirs class and calls it at the end of updateWithStatus(), right after the cascade finishes and fromContext is reset. At that point the tombstones have served their purpose and can safely be removed.

This is the natural cleanup point: it runs after each merge of changes into the context state, matching the lifecycle of the tombstones themselves.

cc @skiplabsdaniel

[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.