`LLVMOrcLLJITLookup` crashes with STATUS_ACCESS_VIOLATION when querying an internal-linkage global variable

**Title**: `LLVMOrcLLJITLookup` crashes with STATUS_ACCESS_VIOLATION when querying an internal-linkage global variable

**Body**:

### Description

`LLVMOrcLLJITLookup` crashes with `STATUS_ACCESS_VIOLATION` (0xC0000005) when called on a global variable with `LLVMInternalLinkage`. The crash occurs after the module containing the internal global has been materialized (triggered by a prior lookup of an exported function in the same module).

The C API should return an appropriate error (e.g. "symbol not found") for non-exported symbols, not crash.

Notably, the crash is **only triggered by the lookup call itself**. If the call to `LLVMOrcLLJITLookup` for the internal symbol is simply skipped, the JIT module works correctly — the exported function can be called and returns the expected result. This confirms the module materialization is successful and the crash is isolated to the lookup path for non-exported symbols.

### Steps to Reproduce

1. Download the official LLVM 22.1.8 Windows MSVC release:
```
https://github.com/llvm/llvm-project/releases/download/llvmorg-22.1.8/clang+llvm-22.1.8-x86_64-pc-windows-msvc.tar.xz
```
2. Extract the archive and copy `LLVM-C.dll` from `bin\` to the current directory.
3. Save the attached reproducer as `orc_global_lookup_repro.c` in the same directory.
4. Compile:
```
gcc orc_global_lookup_repro.c -l:LLVM-C.dll -o main.exe -I include -L .
```
5. Run:
```
main.exe
```

### Expected Behavior

The call to `LLVMOrcLLJITLookup(jit, &addr, "gv")` for an internal-linkage global should return an error indicating the symbol is not exported. The program should continue running and print an error message, not crash.

### Actual Behavior

The process crashes with `STATUS_ACCESS_VIOLATION` (exit code `3221225477` / `0xC0000005`). Sample output:

```
Lookup 'get_gv' OK: addr=000001D1E8F40000
About to lookup internal symbol 'gv' ...
process crashed; code=3221225477
```

### Environment

- **LLVM version**: 22.1.8 (official MSVC pre-built package from GitHub Releases)
- **Download URL**: https://github.com/llvm/llvm-project/releases/download/llvmorg-22.1.8/clang+llvm-22.1.8-x86_64-pc-windows-msvc.tar.xz
- **OS**: Windows 10/11 x64
- **Compiler**: MinGW-w64 GCC (compiling the reproducer against the official MSVC-built `LLVM-C.dll`)

> **Note on MinGW + MSVC DLL**: The LLVM-C API is a pure C ABI, so linking from MinGW against an MSVC-compiled DLL is well-defined and widely used. Additionally, the same crash has been reproduced in an application that loads `LLVM-C.dll` dynamically via `LoadLibrary` (no compile-time linking), which rules out any ABI mismatch as the cause.

### Attached Files

The full LLVM archive (800+ MB) and `LLVM-C.dll` (70 MB) exceed GitHub's 10 MB attachment limit. The following are attached:

- **`orc_global_lookup_repro.c`** — The reproducer source code
- **`main.exe`** — The reproducer compiled with the official LLVM 22.1.8 headers and DLL

The `include/` headers and `LLVM-C.dll` used are from the official LLVM 22.1.8 Windows MSVC release. For reference, the reproducer directory layout is:

```
llvm-error/
├── include/ # extracted from clang+llvm-22.1.8-x86_64-pc-windows-msvc/include/
│ └── llvm-c/
│ ├── Core.h
│ ├── LLJIT.h
│ ├── Target.h
│ ├── TargetMachine.h
│ └── ...
├── LLVM-C.dll # extracted from clang+llvm-22.1.8-x86_64-pc-windows-msvc/bin/LLVM-C.dll
├── main.exe # compiled reproducer
├── orc_global_lookup_repro.c # source code
└── orc_issue_body.md # this file
```

To reproduce from scratch, download the full archive from:

https://github.com/llvm/llvm-project/releases/download/llvmorg-22.1.8/clang+llvm-22.1.8-x86_64-pc-windows-msvc.tar.xz

Then compile and run as described in Steps to Reproduce above.

**Labels**: `orcjit`, `bug`

[files.zip](https://github.com/user-attachments/files/31350315/files.zip)

Start with the attached orc_global_lookup_repro.c and run it against the stated LLVM 22.1.8 Windows package to confirm the crash. Trace the LLVMOrcLLJITLookup entry point for an internal-linkage symbol after materialization. Done means the lookup returns an appropriate error and the process continues without affecting the exported-function lookup.

Written by the indexing model from the issue text.