microcosm.blue
so far there has been at least one spurious birth: the detection logic thought it was new, but we already had that collection indexed
these are harmless (long as we don't try to single-delete on death)
need to sit down and understand the edge case better though, in particular to understand if it's possible that any actually important events would get accidentally filtered out.
i think it may be possible to get spurious deletes. the proof path in a commit for delete might not be required to include both immediate-adjacent keys like i think it is (i think????) for proof-of-absense responses from
com.atproto.sync.getRecord.the good news is deletes are quite infrequent, and deletes that lie on MST node boundaries are more infrequent, so we can hit the upstream repo to check on every delete-that-may-be-spurious.