[mhucka]

This fixes b/510434181, "Out-of-Bounds Iterator Arithmetic and Segfault in getOpForPISP". The vulnerability report flagged the getOpForPISP helper function for constructing new qubit ranges using arithmetic on iterators (such as cur_op_qubits.begin() + use_target) without validating that the array has sufficient elements. If a caller submits a program proto with a PISP gate containing fewer than 2 qubits (or 0), these expressions produce iterators outside valid bounds.

Normally, Cirq in Python prevents you from putting a 2-qubit gate on 0, 1, or 3 qubits. However, tfq_ps_decompose accepts raw serialized strings (tf.string) directly from Python, so a caller or fuzzer or AI agent can pass a hand-crafted Program protobuf where an Operation has the wrong number of qubits attached. This is unlikely to happen in realistic uses because other parts of TFQ would probably catch such invalid constructs, but it is not too difficult to guard against, and we may as well address this in-principle vulnerability to save ourselves the trouble of dealing with future reports about the same issue.

This PR changes tfq_ps_decompose_op.cc as follows:

1. Inside the loop over operations in Compute, each of the four gate branches now checks cur_op.qubits_size() (the C++ protobuf equivalent of len(cur_op.qubits)) before doing anything else.

2. In getOpForPISP, iterator math has been replaced with direct indexing.

3. Errors are more safely reported across parallel CPU threads, using NESTED_FN_STATUS_SYNC.

In addition to that, there are some new tests.

This work was done with the help of Google Gemini.