[xpu-alignment] index_add with negative out-of-bounds index causes XPU kernel SIGABRT instead of Python RuntimeError

### 🐛 Describe the bug

`torch.index_add` with a negative index aborts the Python process on XPU instead of raising a catchable Python out-of-bounds error.

This was found during XPU alignment for upstream PyTorch issue https://github.com/pytorch/pytorch/issues/185885. The upstream issue is an Inductor eager-parity bug: compiled `torch.index_add` accepts an invalid negative index while eager mode raises. The XPU result is a related but different failure: even eager XPU execution lets the invalid index reach the XPU kernel, where a `SYCL_KERNEL_ASSERT` aborts the process.

### Reproducer

```python
import torch

print("torch", torch.__version__)
print("xpu available", torch.xpu.is_available())

device = "xpu"
inp = torch.zeros(4, device=device)
source = torch.ones(1, device=device)
neg_index = torch.tensor([-1], device=device, dtype=torch.long)

inp.index_add(0, neg_index, source)
```

### Actual behavior

The process aborts with an XPU kernel assertion instead of raising a Python exception:

```text
AssertHandler::printMessage
/__w/pytorch/pytorch/third_party/torch-xpu-ops/src/ATen/native/xpu/sycl/Indexing.cpp:914:
operator(): Assertion `dstIndex < dstAddDimSize_` failed.
```

The local alignment run classified this as `related-failure`.

### Expected behavior

XPU should report a catchable Python error for the invalid index, matching eager CPU semantics instead of terminating the process.

Note that the exact error depends on the rank of `self` (verified on CPU):

- 1-D `self`, as in the reproducer above:

```text
IndexError: index out of range in self
```

- `self` with more than one dimension, e.g. `inp = torch.zeros(4, 3)` with `source = torch.ones(1, 3)`:

```text
RuntimeError: index -1 is out of bounds for dimension 0 with size 4
```

The reproducer in this issue uses a 1-D `self`, so the expected result is the `IndexError` form. A previous revision of this section quoted the multi-dimensional `RuntimeError` message, which does not match the reproducer. Tests should assert the message corresponding to the rank under test rather than accepting either error type.

### Alignment metadata

- Upstream source: https://github.com/pytorch/pytorch/issues/185885
- Source type: upstream issue
- Scan window: 2026-06-01 to 2026-06-07
- Local XPU result: related-failure
- Routed area: `intel/torch-xpu-ops`, XPU indexing / kernel assertion behavior

### Notes

This issue should track the XPU hard-abort behavior. It should not be treated as fully resolved by a host-side synchronous bounds check unless the proposed fix also preserves expected async behavior and aligns with CUDA-style error handling. A broader fix at the XPU assertion/runtime layer may be preferable if the same `SYCL_KERNEL_ASSERT` abort pattern affects other kernels.

### Versions

```text
PyTorch version: 2.14.0.dev20260623+xpu
OS: Ubuntu 22.04.5 LTS (x86_64)
Python version: 3.10.12
Is XPU available: True
Intel GPU: Intel(R) Data Center GPU Max 1100
Relevant path: third_party/torch-xpu-ops/src/ATen/native/xpu/sycl/Indexing.cpp
```

Start by running the Python XPU reproducer and compare its behavior with the CPU cases described in the issue. Then inspect third_party/torch-xpu-ops/src/ATen/native/xpu/sycl/Indexing.cpp around the assertion at line 914; done means invalid negative indices produce catchable, rank-appropriate Python errors instead of SIGABRT while preserving the stated asynchronous-error considerations.

Written by the indexing model from the issue text.