[copybara-service]

Validate untrusted DpfKey fields and fix DPF value type helpers.

ProtoValidator::ValidateDpfKey checked the structure of a DpfKey but not its
contents: it accepted party values other than 0 and 1, which evaluation
inconsistently treats as party 1 for control bits and as party 0 for output
negation, and it did not check that value corrections are valid elements of
the level's value type. Uint128To only range-checked the low 64 bits, so a
128-bit proto integer with non-zero high bits was silently truncated when
converted to a narrower type. BitsNeeded indexed the first num_other tuple
elements instead of the non-IntModN ones, so a tuple listing IntModN elements
first was sized from the wrong element types.

A malformed key, which only affects the submitting client's own evaluation,
was evaluated into meaningless output shares instead of being rejected, and
the same correction could be encoded in several ways; these are robustness
and canonical-encoding fixes, not a privacy fix. The BitsNeeded fix changes
PRG output sizing, and therefore generated keys, only for tuples in which
IntModN elements precede other elements. No production value type is
affected: the Privacy Sandbox ReachTuple types are all-integer or all-IntModN.

Reject keys whose party is not 0 or 1 or whose value corrections fail
ValidateValue, reject non-zero high 64 bits in Uint128To, and skip IntModN
elements when sizing the remaining tuple elements. A stale 34-bit value for a
32-bit type in the validator's test key is corrected. Tests cover invalid
parties at validation and evaluation time, oversized and high-bit
corrections, high-bit conversion for every integer width, and order-independent
BitsNeeded for mixed tuples.