This issue is about growing contents of the ProcessesListening deduper in the `updatecomputer.TransitionBased` implementation. Due to inconsistency in handling ProcessesListening updates (number of 'open' messages may be higher than the number of 'close' messages), the deduper state may grow indefinitely. This is caused by adding a deduper entry when 'open' message for ProcessesListening is processed, and removing when `close` message is observed.

Assumption: Based on conversation with the Collector team (mid of calendar-week 38 2025), we can assume that single endpoint would have maximally one process listening. It is theoretically possible that multiple processes attach to the same endpoint, but for now, we can assume that this is not supported. Thus, I assume that each endpoint may have 0 or 1 ProcessesListening. That implies that if an `endpoint1` is seen with `process1` and later there is an 'open' message for `endpoint1` with `process2`, then it implies that the `process1` should be closed without any direct instruction to do so from Collector.

Assumption before:

1. Open endpoint1+process1 (arrives from collector, yields update to Central)
2. Close endpoint1+process1 (arrives from collector, yields update to Central)
3. Open endpoint1+process2 (arrives from collector, yields update to Central)

Assumption after:

1. Open endpoint1+process1 (arrives from collector, yields update to Central)
2. Open endpoint1+process2 (arrives from collector, yields update to Central)
   1. Triggers internal removal of `process1` from Sensor memory
   2. Optionally triggers update to Central that `process1` was closed.