[WebAssembly][Object] Consider recoverable diagnostic for overlong ULEB128 in malformed Wasm input

### Summary

This is a non-security issue / behavior clarification request.

I have a small malformed WebAssembly input containing an overlong ULEB128-like sequence. When processed by LLVM object/debug-info tooling, LLVM terminates through a fatal error path with:

```text
LLVM ERROR: uleb128 too big for uint64
```

LLVM security triage indicated that this should not be treated as a security vulnerability. I am therefore filing this only as a possible diagnostic behavior improvement: should malformed Wasm object input return a recoverable object-parse error instead of terminating the process?

If this fatal diagnostic is intended behavior, please feel free to close this as expected behavior.

### Affected area

```text
LLVM Object / WebAssembly object parsing
```

Observed with:

```text
llvm-dwarfdump
llvm-objdump --file-headers
LLVM object parsing API usage
```

### Test input

The malformed input is 23 bytes:

```text
00 61 73 6d 01 00 00 00 c1 c1 c1 c1 c1 98 98 c1 c1 c1 c1 c1 c1 c1 c1
```

It starts with a WebAssembly magic/version header and then contains an overlong ULEB128-like sequence.

### Observed behavior

Example output:

```text
LLVM ERROR: uleb128 too big for uint64
```

The observed path involves LLVM Object / Wasm parsing reaching a fatal error path while decoding the malformed input.

### Expected behavior / question

If LLVM intends object parsing APIs and tools to handle malformed object files recoverably, the expected behavior would be a normal diagnostic and non-zero exit status, for example:

```text
error: malformed Wasm object: uleb128 too big for uint64
```

If the current fatal termination is intended for this malformed input, then this issue can be closed as expected behavior.

### Reproducer

A public reproducer is available here:

```text
https://github.com/fa1c4/security-advisories/tree/main/LLVM
```

I can rename/move the repository if the current path is confusing, since this is no longer being treated as a security issue.

General reproduction flow:

```bash
docker build -t llvm-wasm-uleb128-repro .
docker run --rm llvm-wasm-uleb128-repro
```

The reproducer runs the malformed input through LLVM command-line tools and a small API-level reproducer.

### Tested versions / contexts

```text
LLVM 18.1.3 from Ubuntu noble packages
LLVM 23.0.0git OSS-Fuzz context
```

Exact affected range is unknown.

### Notes

This issue is not a request for security treatment, CVE assignment, or advisory publication. It is only a question about whether this malformed-input path should return a recoverable diagnostic rather than terminating through the fatal error path.

Start with the linked Docker reproducer and run the malformed 23-byte input through llvm-dwarfdump, llvm-objdump --file-headers, and the API-level reproducer. Trace the WebAssembly object-parsing entry point that emits “uleb128 too big for uint64”; done means either a recoverable malformed-object diagnostic with a non-zero exit status or confirmation that fatal termination is intended.

Written by the indexing model from the issue text.