[clr-interp] Fail with a BADCODE if the opcode is unknown

[davidwrighton]

• Fail with BADCODE instead of asserting, which allows us to complete running some of the test suites, and will actually do the desired thing in actual retail builds.
• Also protect against unsafe memory access by bounds checking in CEEOpName

[Copilot]

Pull Request Overview

This PR improves error handling in the CLR interpreter by replacing assertion failures with proper BADCODE exceptions when encountering unknown opcodes. This allows test suites to complete execution rather than crashing on unsupported operations.

• Replace assert() calls with BADCODE() macro for unknown opcodes and unsupported static field accessors
• Add bounds checking in CEEOpName() to prevent unsafe memory access when looking up opcode names
• Wrap debug output in #ifdef DEBUG to reduce overhead in release builds

Reviewed Changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.

File	Description
src/coreclr/interpreter/intops.cpp	Added bounds checking to prevent array access beyond valid opcode range
src/coreclr/interpreter/compiler.cpp	Replaced assertions with BADCODE exceptions and added debug-only output

[kg]

Will using BADCODE break fallback to JIT?

[davidwrighton]

Maybe, but we don't really want that fallback if it isn't fixing things, and the current path is just an assert which is just wrong.