reject out-of-range constant pool index in SegmentConstantPool

[kali834x]

Out-of-range constant pool index in the pack200 unpacker

SegmentConstantPool.getConstantPoolEntry and getValue resolve a bytecode reference operand into a constant pool entry but only reject negative indices (via toIndex), then hand the value straight to CpBands.cpUTF8Value / cpClassValue / cpMethodValue / ..., each of which reads its backing array with no upper bound. A crafted archive whose operand points past the pool makes those accessors throw ArrayIndexOutOfBoundsException out of setByteCodeOperands, escaping the declared Pack200Exception contract of Archive.unpack. Both resolvers now report the out-of-range index as a Pack200Exception, matching how the negative case is already handled. This is distinct from #788 (which bounds BandSet.getReferences, the constant-pool structure resolver) and #805 (negative operands): the gap here is the too-large index on the bytecode-operand path.

• Read the contribution guidelines for this project.
• Read the ASF Generative Tooling Guidance if you use Artificial Intelligence (AI).
• I used AI to create any part of, or all of, this pull request. Which AI tool was used to create this pull request, and to what extent did it contribute? Claude was used to help locate the missing bound, draft the fix, and write the regression test; I reviewed and verified the change.
• Run a successful build using the default Maven goal with mvn; that's mvn on the command line by itself.
• Write unit tests that match behavioral changes, where the tests fail if the changes to the runtime are not applied. This may not always be possible, but it is a best practice.
• Write a pull request description that is detailed enough to understand what the pull request does, how, and why.
• Each commit in the pull request should have a meaningful subject line and body. Note that a maintainer may squash commits during the merge process.

[kali834x]

any update?