Crash in intrinsifying heap-based MemorySegment Vector store/loads

Bug reported by joel.knighton@datastax.com on panama-dev:
Experiencing a reliable JVM crash from C2 compilation threads that's reproducible on the latest release of 22 as well as fastdebug builds of the master branch.
This appears to have been introduced by JDK-8319111. Post- JDK-8319111, it is possible to attempt to intrinsify a store/load of a mismatched vector through inline_vector_mem_operation. When the mem_elem_bt is T_ILLEGAL this causes the C2 thread to crash in type2aelembytes (fastdebug) or vector_width_in_bytes (release).
A small reproducer is attached. This reliably reproduces the issue on x86 under UseAVX=2 or UseAVX=3:

#
# A fatal error has been detected by the Java Runtime Environment:
#
# Internal Error (/home/XYZ/src/openjdk/jdk/src/hotspot/share/utilities/globalDefinitions.cpp:334), pid=326489, tid=326520
# assert((allow_address || t != T_ADDRESS) && t <= T_CONFLICT) failed: unexpected basic type
#
# JRE version: OpenJDK Runtime Environment (23.0) (fastdebug build 23-internal-adhoc.XYZ.jdk)
# Java VM: OpenJDK 64-Bit Server VM (fastdebug 23-internal-adhoc.XYZ.jdk, mixed mode, tiered, compressed oops, compressed class ptrs, g1 gc, linux-amd64)
# Problematic frame:
# V [libjvm.so+0xdd4dfd] type2aelembytes(BasicType, bool)+0x5d
...
...

--------------- T H R E A D ---------------

Current thread (0x0000748ff4312750): JavaThread "C2 CompilerThread0" daemon [_thread_in_native, id=326520, stack(0x0000748fd8375000,0x0000748fd8475000) (1024K)]


Current CompileTask:
C2:3777 975 4 jdk.incubator.vector.ByteVector::intoMemorySegment (48 bytes)

Stack: [0x0000748fd8375000,0x0000748fd8475000], sp=0x0000748fd846fa60, free space=1002k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V [libjvm.so+0xdd4dfd] type2aelembytes(BasicType, bool)+0x5d (globalDefinitions.cpp:334)
V [libjvm.so+0x199f6c0] LibraryCallKit::inline_vector_mem_operation(bool)+0x920 (vectorIntrinsics.cpp:1042)
V [libjvm.so+0x1289585] LibraryIntrinsic::generate(JVMState*)+0x1c5 (library_call.cpp:118)
V [libjvm.so+0x87c78e] CallGenerator::do_late_inline_helper()+0x9fe (callGenerator.cpp:700)
V [libjvm.so+0xa1c420] Compile::inline_incrementally_one()+0xf0 (compile.cpp:2050)
V [libjvm.so+0xa1d139] Compile::inline_incrementally(PhaseIterGVN&)+0x239 (compile.cpp:2133)
V [libjvm.so+0xa1f0c8] Compile::Optimize()+0x358 (compile.cpp:2268)
V [libjvm.so+0xa236d0] Compile::Compile(ciEnv*, ciMethod*, int, Options, DirectiveSet*)+0x1bd0 (compile.cpp:861)
V [libjvm.so+0x874b87] C2Compiler::compile_method(ciEnv*, ciMethod*, int, bool, DirectiveSet*)+0x1b7 (c2compiler.cpp:142)
V [libjvm.so+0xa2ffe0] CompileBroker::invoke_compiler_on_method(CompileTask*)+0xb50 (compileBroker.cpp:2310)
V [libjvm.so+0xa30d88] CompileBroker::compiler_thread_loop()+0x518 (compileBroker.cpp:1969)
V [libjvm.so+0xefd9de] JavaThread::thread_main_inner()+0xee (javaThread.cpp:760)
V [libjvm.so+0x1923b0e] Thread::call_run()+0xbe (thread.cpp:221)
V [libjvm.so+0x150c5ba] thread_native_entry(Thread*)+0x12a (os_linux.cpp:853)