fix: preserve errored items through Filter to prevent silent error loss

[MasterOfBinary]

Summary

processor.Filter ran its predicate on every item, including items a prior processor had already marked with an Error. If the predicate excluded such an item, it was dropped from the batch and its error never reached the engine's error channel — silent error loss when a Filter follows an error-producing stage.

Fix

Items with item.Error != nil now pass through the filter unconditionally; the predicate (and InvertMatch) apply only to error-free items. Godoc on Filter and Process documents the guarantee.

Testing

• TDD: a test placing an errored item the predicate would exclude failed first (item dropped, error lost), and passes after the fix.
• Covers: normal filtering of error-free items, InvertMatch, errored-item passthrough (including with InvertMatch: true), and nil-predicate passthrough.
• go test -race ./... green · go vet / gofmt clean.

Backwards compatibility

No exported API signatures changed. Behavior changes only for already-errored items (now preserved instead of possibly dropped) — a strict bug fix.

---

Part of a 5-PR set from a full-repo review; file-disjoint and independently mergeable in any order.

🤖 Generated with Claude Code

[gemini-code-assist]

Code Review

This pull request modifies the Filter processor to ensure that items already carrying an error are passed through unchanged, preventing their errors from being silently discarded before reaching the engine's error-reporting step. Comprehensive unit tests have been added to verify this behavior under various scenarios, including with the InvertMatch option. The reviewer suggested adding a defensive nil check on item within the processing loop to prevent potential nil pointer dereference panics if nil items are passed into the processor.

[gemini-code-assist]

To prevent potential nil pointer dereference panics, it is highly recommended to perform a defensive nil check on item before accessing its fields or passing it to the predicate function. If an upstream processor or external caller passes a slice containing nil elements, this check ensures the application remains stable and does not panic.

Suggested change

	if item.Error != nil {
	result = append(result, item)
	continue
	}
	if item == nil {
	continue
	}
	if item.Error != nil {
	result = append(result, item)
	continue
	}

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 96.76%. Comparing base (ba2a756) to head (ad8de09).

Additional details and impacted files

@@            Coverage Diff             @@
##           master      #66      +/-   ##
==========================================
+ Coverage   96.73%   96.76%   +0.02%     
==========================================
  Files          12       12              
  Lines         368      371       +3     
==========================================
+ Hits          356      359       +3     
  Misses          9        9              
  Partials        3        3              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[MasterOfBinary]

Declining the nil-check suggestion: nil items can only arise from a processor violating the chain contract — the engine never creates them (batch/batch.go:374) — and they'd panic in Transform/Channel/Error and the engine's final error scan regardless, so a check in Filter alone adds inconsistency without real safety. Silently continue-ing past a nil would also reintroduce exactly the silent-drop behavior this PR removes. Engine-level handling of malformed processor returns (including nil elements) is tracked in #87.