fix(sdk): filter batch items on status alone

[vyrnsynx]

Issue #, if available:: Closes #760

Description of changes:

succeeded() and get_results() also checked item.result is not None, so a branch that returned None was counted in success_count but dropped from both. failed() and get_errors() had the same check on item.error.

Following the approach suggested in #760:

• succeeded() and failed() select items by status alone. get_results() and get_errors() are built from them with a cast, so the return types stay list[R] and list[ErrorObject]
• When replay rebuilds a FAILED item from a child context checkpoint that has no error (_replay_terminal_item and _replay_from_checkpoints), it now records the generic ChildContextError that replaying that child context raises. Every FAILED item has an error, and throw_if_error() raises for it
• test_batch_result_failed_with_none_error asserted the old filter, so it now expects the FAILED item to be kept

For the release notes: get_results() can now contain None when a branch returns nothing, so something like sum(batch.get_results()) raises in that case.

Testing:

• New tests fail on main and pass with the change: BatchResult with None results, a live execute() over branches returning [None, 10, None, 30], and both replay paths with a FAILED checkpoint that has no error
• hatch run dev-core:cov: 1769 passed, 98.23% coverage
• hatch run test:all: 4080 passed, 2 skipped
• hatch run types:check and hatch fmt --check in the core package: passed

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

[zhongkechen]

cast() only changes static typing; it leaves None unchanged. BatchItem(..., FAILED, error=None) remains accepted (including in test_batch_result_failed_with_none_error), and BatchResult.from_dict() also permits it. These paths bypass _failed_checkpoint_error_object(), so get_errors() can return [None] despite its list[ErrorObject] contract. I reproduced this after a default ExtendedTypeSerDes round trip; accessing error.type then raises AttributeError.

Could we normalize missing failed-item errors at the model/deserialization boundary using the same generic ChildContextError, and extend the regression test to cover get_errors() after deserialization? That would preserve one error per failed item while making the return type accurate.

[vyrnsynx]

Good catch — cast() was only papering over the typing hole.

I normalized missing FAILED-item errors at the model boundary (BatchItem.__post_init__ / from_dict), using the same generic ChildContextError message the executor already records via _failed_checkpoint_error_object when a child-context checkpoint has no ErrorObject. get_errors() still falls back defensively.

Extended test_batch_result_failed_with_none_error to assert get_errors() after construction, after from_dict of an error: null wire payload, and after an ExtendedTypeSerDes round-trip of that same null-error payload (the path that was raising AttributeError on error.type).