feat(py): require a live Operation on check and cancel

[huangjeff5]

Summary

• check_operation / cancel_operation take a live Operation. A persist dump is Operation.model_validate(dumped) first. Extra keys (latencyMs) are ignored so that validate does not 500.
• Published check/cancel input schema stays one Operation (extra='ignore'). Not Operation | dict.
• A raw dump, a boxed ModelResponse, or a str is INVALID_ARGUMENT (not AttributeError). Messages: got a dump; pass Operation.model_validate(...), got ModelResponse; pass response.operation, got str, expected Operation.
• The same gate runs on BackgroundAction.check / BackgroundAction.cancel, so a dump cannot AttributeError on .action before UNIMPLEMENTED.
• Missing cancel fn is UNIMPLEMENTED on both the veneer and a real BackgroundAction.cancel. Unknown action is INVALID_ARGUMENT.

[google-cla]

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

[gemini-code-assist]

Code Review

This pull request updates the background operation polling and cancellation mechanisms to accept both live Operation objects and raw dictionary mappings (persisted poll handles), ignoring extra keys like latencyMs to prevent failures during reload. It also introduces more robust error handling using GenkitError and adds comprehensive unit tests. The review feedback suggests two performance optimizations: avoiding redundant serialization/re-validation when the input is already an Operation instance, and precomputing the set of valid operation fields to avoid linear scans in is_operation_field.