feat(flexible-outcalls): CON-1709 harden ResponsesTooLarge validation with all-seen-shares proof

[fspreiss]

Strengthens the ResponsesTooLarge error for flexible HTTP outcalls to prevent a malicious block proposer from fabricating the error by selectively omitting small OK shares.

• Renamed metadata_shares → all_seen_shares in FlexibleCanisterHttpError::ResponsesTooLarge and the corresponding protobuf message, so the error now carries all seen shares (both OK and reject), not just a subset.
• Updated the builder (find_flexible_result) to emit all OK and reject shares into all_seen_shares.
• Rewrote the validator logic to use is_reject (from CON-1708) to partition shares, compute num_unseen and min_known_ok_needed, and verify that the smallest set of OK responses genuinely exceeds MAX_CANISTER_HTTP_PAYLOAD_SIZE. An early check rejects payloads with too few OK shares before computing sizes.
• Replaced FlexibleInsufficientMetadataShareCount with the more descriptive FlexibleResponsesTooLargeInsufficientEvidence error variant.
• Added comprehensive validation tests: mixed OK/reject shares, unseen committee members, attack-vector scenarios (committee members omitted), and insufficient OK share counts.

Attack vector closed

Previously, a malicious proposer could craft a ResponsesTooLarge error by including only a few hand-picked large OK shares while omitting committee members who submitted small responses. The validator would check only the provided shares and accept the error as valid.

Now, the validator computes num_unseen = committee_size - all_seen_shares.len() and min_known_ok_needed = min_responses - num_unseen. Since unseen members could have submitted zero-size OK responses, the validator conservatively assumes they did. A proposer who omits members increases num_unseen, which lowers min_known_ok_needed, making it harder to prove responses are too large—the opposite of what an attacker wants.

Test plan

• flexible_build_responses_too_large — builder emits all 4 OK shares
• flexible_build_responses_too_large_with_rejects_reducing_unseen — builder emits 3 OK + 2 reject shares
• flexible_error_responses_too_large_valid — all committee members with huge OK → accepted
• flexible_error_responses_too_large_valid_with_unseen_members — legitimate error with 1 unseen member → accepted
• flexible_error_responses_too_large_valid_with_mixed_ok_and_reject — 2 huge OK + 2 reject, all seen → accepted
• flexible_error_responses_too_large_invalid_when_small — small OK shares + high unseen → rejected (min_known_ok_needed=0)
• flexible_error_responses_too_large_invalid_when_committee_members_omitted — attacker omits members, num_unseen defeats the claim → rejected
• flexible_error_responses_too_large_too_few_ok_shares — not enough OK shares for min_known_ok_needed → InsufficientEvidence
• Existing tests for duplicate signers, callback mismatch, non-committee signers, registry version mismatch, and invalid signatures continue to pass