@lrhodes @gvelez17 @shiri @snarfed.org
The bridge can't really filter in this direction, since afaik AT firehose subscriptions and repository fetch are anonymous(-ish). Rather, it's Eta's PDS (and optionally feed algorithms on the way, but only as optimisation) that enforces the bridged block. Delta's instance should also stop sending posts to the bridge, as AP does not use a firehose, but only if there are no other (not-blocked) bridged Bsky followers.
A meaningful desync happens only when the block is rescinded: The bridge may have to automatically re-follow Delta as Eta to restore consistency, since I don't think you can 'remove a follower' on AT.
What happens with a follow in the other direction depends on whether there are separate block and unfollow activities generated by Mastodon. If yes, then no desync happens and Delta('s software) can choose whether they still follow Eta after the block is gone. If blocking does imply unfollowing in AP, then the bridge would have to translate AP blocks into AT block-and-unfollow.
Delta would then not follow Eta after the block is gone, unless Delta('s instance) re-follows Eta explicitly.
Maybe there's some inconsistency detection and cleanup scheme built into one or both of the protocols, too, in which case the bridge should make use of that where possible. I'm not aware of such a mechanism, though.