This is definitely a concern, and it is due to properties not being “facts” but instead “claims”. There’s some work in fep/fep/0391/fep-0391.md at main - fediverse/fep - Codeberg.org in using result of an Activity to point to the side effect being successfully carried out, for example having a Create.Object.inReplyTo trigger Add<Object>.target<Object.inReplyTo.replies> should be reflected in Create.result probably. There’s also some work in pointing to this same Add activity with properties like inReplyToProof and contextProof, as well as a desire to have some way of going from an Object to its corresponding Create. FEP-0391: Special collection proofs is the discussion thread for that. (Side note, there should probably also be some consideration for signaling some kind of undoneBy property or a way to otherwise Update an Add to signal that it shouldn’t be used for such attestation, i.e. that its purpose as a stamp has been revoked.)
Even with this in mind, I still think that right now we have no way of going from an object to a collection, so we can’t even begin to verify this claim because we can’t even make this claim. We only have claims for specific semantic usages, like inReplyTo implying possible inclusion in the inReplyTo.replies collection, and context implying possible inclusion in a context collection (if context resolves to a collection). But even if you don’t verify these as bidirectional claims, they still exist as singly-linked claims – an object’s inclusion in a replies collection doesn’t have any bearing on whether the object is in fact a response to the inReplyTo, and an object’s inclusion in a context collection doesn’t have any bearing on whether the object is in fact contextual to that context.
So likewise, having collections claim certain items, and having items be able to claim certain collections, is something that should be verified in both directions, but each side of that claim continues to exist separately from the bidirectional claim (which needs verifying).
Another thing that could help is support for querying collections, either broadly/generally with something like SPARQL (which makes a lot of sense for LD-aware clients, but might be overkill and overly complicated for LD-unaware clients), or something far more narrow/specific like Smithereen’s collectionSimpleQuery which doesn’t do anything other than tell you if an object is included in a collection.