cap fullStage2Length to avoid size overflow in reconstituteData

[rootvector2]

Description

reconstituteData() in the MBCS converter loader computes
dataLength = stage1Length*2 + fullStage2Length*4 + fromUBytesLength in uint32_t.
A table with a large fullStage2Length wraps this sum to a small value, so uprv_malloc
allocates an undersized buffer that the following uprv_memcpy and stage-2 pointer
arithmetic overrun.

This adds a 64-bit overflow check that rejects the table with U_INVALID_TABLE_FORMAT,
mirroring the other malformed-table guards already in the loader (ucnv_MBCSLoad).

Found while fuzzing the converter loader with mutated .cnv table data.

Checklist

• Required: Issue filed: ICU-NNNNN
• Required: The PR title must be prefixed with a JIRA Issue number. Example: "ICU-NNNNN Fix xyz"
• Required: Each commit message must be prefixed with a JIRA Issue number. Example: "ICU-NNNNN Fix xyz"
• Issue accepted (done by Technical Committee after discussion)
• Tests included, if applicable
• API docs and/or User Guide docs changed or added, if applicable
• Approver: Feel free to merge on my behalf

[markusicu]

• Please restore and fill out the pull request template.
• Please create a Jira ticket with the problem description.
• This appears to be guarding against bad input binary data, which is hard to do comprehensively and not a goal. I will take a look at the context.

[rootvector2]

Restored and filled out the template in the description.

I don't have a Jira account to file the ticket. Can you open one for this overflow, or point me at an umbrella issue to reuse? I'll prefix the title and commit with the number once it exists.

On scope: this isn't comprehensive input validation, just the single uint32_t sum in reconstituteData that wraps. ucnv_MBCSLoad already rejects malformed tables with U_INVALID_TABLE_FORMAT in several spots, so this matches those. Found it fuzzing the loader with mutated .cnv data, and I'm fine to drop it if you'd rather not guard there.