PyTorch sparse in-place add can write past a dense view

An in-place add of a sparse COO tensor into a dense view can silently update the wrong memory, or abort the process, in current PyTorch CPU builds.

The failure shows up when the destination is a contiguous view with a nonzero storage offset, such as a single row of a larger tensor. The sparse add_ kernel applies that offset twice. For a three-row buffer, adding a length-8 sparse vector of ones into row 1 leaves that row untouched and writes the ones into row 2 instead. If the view sits at the end of the allocation, the write lands past the buffer. glibc then reports heap corruption (invalid next size, or an invalid fastbin entry) and the process aborts with SIGABRT.

That is the opposite of what the sparse docs promise. Tensor.add_ is listed as supported for COO tensors, and the result should match adding the same values after converting them to a dense tensor.

The bug was hit while testing TensorDict's in-place math on collections of sparse COO tensors. It reproduces on the 2.11.0 and 2.15.0 CPU wheels and on a 2.16 development build from 11 November 2026, all on Linux. When the destination buffer happens to be large enough, the only symptom is a wrong answer.