I think you’re conflating two different things here.
The first thing is Structured Exception Handling.
This is all about, when something goes wrong, the code going in search of something that can deal with it (i.e. an Exception Handler). That handler will either “handle” the Exception completely, causing it to be resolved and, therefore, making it “go away” or it will throw the Exception (or a related one) again, in an attempt to find something else that can deal with it.
Typically, your “global” Exception Handler is only a “backstop” that catches everything, makes sure it’s safely recorded for later diagnostic work and then lets the process crash and burn.
So, your idea of marking whether an Exception has been “handled” or not is not really valid. Either an Exception Handler deals with the Exception or it passes it along to something else.
Where I have seen this principle is in Event propagation, where one, raised, Event can be passed around many subscribers and each needs to know whether whether or not the Event is still “Live”.
The second thing is the handling of Errors in your pipeline processing.
It seems to me that any stage in your pipeline can go wrong and you have a mechanism to detect this and “park” the item for reprocessing later. That’s a really good thing, but it’s not Structured Exception Handling, in itself. Sure, you can (and should) use S.E.H. to initially detect the problems and route the items accordingly, but the Handlers of these Exceptions should “consume” (i.e. not rethrow) such Exceptions, so that the global Exception Handler never sees them.