[SPIR-V] Backend crashes on IR that stores a vector of pointers (`isValidElementType` assertion)

An application is failing to compile with clang when targeting SPIR-V. From pulling out the .bc of the compile line, and running `llvm-reduce` to get a minimal IR, it looks like the issue is from the SPIR-V backend crashing on IR that stores a vector of pointers.

The original IR comes from a HIP application compiled with chipStar at -O2 (CHIP-SPV/chipStar#1454, reported there first in case it was
chipStar-specific). The application code has a struct with several pointer members, and it looks like the optimizer turns copies of it into a vector of pointers in the IR. The reproducer below is from rerunning the failing compile with `--save-temps` to get the .bc and then running `llvm-reduce` on the .bc, resulting in `bug.ll`.

This was tested with a stock unpatched LLVM at the `llvmorg-23.1.0-rc3` tag (commit 7196f931f), built with `-DCMAKE_BUILD_TYPE=Release -DLLVM_ENABLE_ASSERTIONS=On -DLLVM_TARGETS_TO_BUILD=host DLLVM_EXPERIMENTAL_TARGETS_TO_BUILD=SPIRV`.

## Reproducer

```llvm
target triple = "spirv64"

define spir_kernel void @k(ptr addrspace(1) %src, ptr addrspace(1) %dst) {
entry:
%v = load <4 x ptr addrspace(4)>, ptr addrspace(1) %src, align 8
store <4 x ptr addrspace(4)> %v, ptr addrspace(1) %dst, align 8
ret void
}
```

## Compiling

``` bash
llc -mtriple=spirv64 bug.ll -o /dev/null
```

## Running

The fail looks like:
``` bash
> llc -mtriple=spirv64 bug.ll -o /dev/null
llc: /lus/flare/projects/Aurora_deployment/bertoni/projects/p02.chipStar/test_LLVM/llvm-project/llvm/lib/IR/Type.cpp:869: static llvm::FixedVectorType* llvm::FixedVectorType::get(llvm::Type*, unsigned int): Assertion `isValidElemen\
tType(ElementType) && "Element type of a VectorType must " "be an integer, floating point, " "pointer type, or a valid target " "extension type."' failed.
PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace and instructions to reproduce the bug.
Stack dump:
0. Program arguments: llc -mtriple=spirv64 bug.ll -o /dev/null
1. Running pass 'SPIRV emit intrinsics' on module 'bug.ll'.
#0 0x00000000026a5d9a llvm::sys::PrintStackTrace(llvm::raw_ostream&, int)
#1 0x00000000026a28f8 llvm::sys::RunSignalHandlers()
#2 0x00000000026a2a4b SignalHandler(int, siginfo_t*, void*) Signals.cpp:0:0
#3 0x00007f30882168c0 __restore_rt (/lib64/libpthread.so.0+0x168c0)
#4 0x00007f308792fc6b raise (/lib64/libc.so.6+0x4ac6b)
#5 0x00007f3087931305 abort (/lib64/libc.so.6+0x4c305)
#6 0x00007f3087927c6a __assert_fail_base (/lib64/libc.so.6+0x42c6a)
#7 0x00007f3087927cf2 (/lib64/libc.so.6+0x42cf2)
#8 0x0000000001aaf4aa llvm::FixedVectorType::get(llvm::Type*, unsigned int)
#9 0x000000000092546d (anonymous namespace)::SPIRVEmitIntrinsics::deduceNestedTypeHelper(llvm::User*, llvm::Type*, llvm::SmallPtrSetImpl&, bool) SPIRVEmitIntrinsics.cpp:0:0
#10 0x000000000092e161 (anonymous namespace)::SPIRVEmitIntrinsics::insertPtrCastOrAssignTypeInstr(llvm::Instruction*, llvm::IRBuilder&) SPIRVEmitIntrinsics.cpp:0:0
#11 0x0000000000932305 (anonymous namespace)::SPIRVEmitIntrinsics::runOnFunction(llvm::Function&) SPIRVEmitIntrinsics.cpp:0:0
#12 0x0000000000934a15 (anonymous namespace)::SPIRVEmitIntrinsics::runOnModule(llvm::Module&) SPIRVEmitIntrinsics.cpp:0:0
#13 0x0000000001a2f992 (anonymous namespace)::MPPassManager::runOnModule(llvm::Module&) LegacyPassManager.cpp:0:0
#14 0x0000000001a300ac llvm::legacy::PassManagerImpl::run(llvm::Module&)
#15 0x0000000000842288 compileModule(char**, llvm::SmallVectorImpl&, llvm::LLVMContext&, std::__cxx11::basic_string, std::allocator>&) llc.cpp:0:0
#16 0x000000000079bf6d main
#17 0x00007f308791a24d __libc_start_main (/lib64/libc.so.6+0x3524d)
#18 0x000000000083640a _start
Aborted (core dumped)
```

- We expect this to compile cleanly, as the code is valid IR, based on `llvm-as` and `opt -passes=verify` accepting it, and `llc -mtriple=x86_64-unknown-linux-gnu` compiles the IR cleanly.

- Note that the store is what triggers it. A load of `<4 x ptr addrspace(4)>` alone fails cleanly with `error: ... Vector of pointers requires SPV_INTEL_masked_gather_scatter extension`, but the store path hits the assertion before reaching that diagnostic. Adding `--spirv-ext=all` doesn't avoid the crash either.

Thanks!

Start with the SPIRVEmitIntrinsics pass named in the stack dump and reproduce the crash using bug.ll with `llc -mtriple=spirv64`. Compare the vector-of-pointers store path with the clean load diagnostic and existing SPIR-V handling. Done means valid IR no longer hits the `isValidElementType` assertion and produces the expected compilation result or diagnostic.

Written by the indexing model from the issue text.