you could draw a comparison to smtp where delivery errors might result in a receipt from the mailer daemon that your message was bounced.
the challenge is in knowing who sent the activity in the first place (and therefore to which inbox you should deliver your error). typically this is determined by having a valid http signature, so i guess http signatures would have to be processed synchronously and their errors returned as part of the response. this may already be the case?
after the activity is accepted for further processing, if that processing later fails, then you can send your error report to the inbox of the actor who owns the key that signed the message (Signature.keyId.owner.inbox in current usage). this error report’s payload is open to interpretation – you could use a Reject as proposed in Signaling side effects asynchronously by generalizing Accept/Reject