fix: always panic in Context.Fail

[jalaziz]

Context.Fail is documented to stop the callback immediately by panicking, but syncFailer skipped the panic when the partition's run context was already Done and returned normally instead.

The run context of a partition processor descends from the sarama session context, so it is cancelled whenever a rebalance revokes the partition. A callback that is in flight at that moment, notices the cancellation and reports it through ctx.Fail therefore resumed execution and returned, letting processMessage reach msgContext.finish(nil). The error had been recorded in run's local rerr and never reached the cbContext, so tryCommit found no error and marked the offset of a message that was never processed successfully.

Sarama flushes marked offsets while releasing the session, before rejoining the group, so the commit is accepted for the still valid generation and the next owner of the partition starts after the message, which is therefore lost. run does return an errProcessing and the processor shuts down, but only after the offset has been marked, so the shutdown does not prevent this.

Panicking unconditionally restores the documented contract and skips the commit, because the panic keeps processMessage from calling finish. It is recovered by the existing handler in run, which records the error and performs the waitgroup accounting, so the processor still terminates with an errProcessing as before.

This intentionally does not make the commit conditional on the run context being alive: a callback that completes successfully has already emitted its messages and written its table updates, so its offset must still be committed even if the partition was revoked in the meantime.