I confirm it's a bug. Thanks a lot for taking the time to provide a reproducer, it was of tremendous help. I'm working on a fix.

Due to the location of the bug (deep inside implementation code), there's unfortunately not a lot you can do to work around the bug. The best you can do is to reindex explicitly just after the merge:

Search.getFullTextSession(s).index(updatedVersion.getItem());

If you cannot realistically know in advance which entities are going to need to be reindex, there is potentially a hack you can use... but it's really a hack: be sure to test it properly. The idea is to ask Hibernate Search to perform an operation that won't change anything, but will have the side effect of initializing some internal structures properly.
After you started your transaction, just trigger a purge operation that you're absolutely sure won't have any effect, by using an entity ID that you're absolutely sure does not match any entity:

Search.getFullTextSession(s).purge(ItemEntity.class, -1);

Then the internal structure for that entity type will be initialized properly, and @ContainedIn processing will work fine for the rest of the transaction.
If you have other indexed types, you will have to do the same for each type that could potentially be affected by your transaction.

Note the purge operation will still be executed, it's just that it won't have any effect since the ID does not match anything.