Build iso from a stride-0 values array; document a bitmap BFS levels Vector - #649

From Nib's letter of 2026-08-27 (items 1 and 2).

np.broadcast_to(np.float64(1), n) is the cheap way to spell n ones, and
from_coo stored n copies of the value for it, which also turns off
is_iso fast paths downstream. (SuiteSparse 10.5.0 dropped the post-build
check that noticed all-equal values.) Matrix.from_coo and
Vector.from_coo now take a 1-d ndarray of a built-in dtype with strides
(0,) and at least one element as its one value and build iso, as a scalar
value does. Everything else is what the array path gives: the dtype comes
from the array (an np.int32 array stays INT32, where the scalar np.int32(-3)
gives INT64), dtype= casts as NumPy casts the array, length mismatches and
duplicate indices raise the same ValueError with the same message, and
out-of-range indices raise the same IndexOutOfBound. With dup_op
given, UDT values or dtypes, 0-length or 2-d arrays, and the vanilla backend,
the general path stays. Matrix.build is unchanged.

A script comparing the two paths over 56160 builds (13 NumPy dtypes, 12
values, 9 dtype= choices, 0-d and 1-element sources, nvals mismatches,
duplicates, explicit shapes, out-of-range indices; Matrix and Vector) found
no difference in result, dtype, exception, message or warnings apart from
is_iso.

Measured (mlx, SuiteSparse 10.5.0, Apple M5 Pro, best of 3 or of 300):

nvals          nbytes              build              mxv plus_times
50,000,000     584.1 -> 202.7 MiB  326 -> 254 ms      16.2 -> 14.6 ms
1,000          12496 -> 4504 B     17.2 -> 19.4 us

with 651 -> 79 MiB of peak RSS above the inputs at 50M, the same as
values=1.0. The small build costs about 2 us more, as a scalar does.

The docs note (user guide, "Opaque Objects") shows a level BFS whose
levels Vector is pinned with sparsity_control = "bitmap", says why
(the masked assign leaves pending tuples that each read as a mask must
merge first) and what it costs (a bitmap cannot compact to full). It also
says to set the option once the Vector has an entry: on SuiteSparse 10.5.0
and 10.5.1, a masked scalar assign into an empty Vector (Method 05e)
rebuilds it from the mask with GB_dup_worker and takes the mask's
sparsity_control, so pinning the empty Vector first did nothing.
Reproduced on a 50 by 20000 grid, 20049 rounds: 0.234 s with "auto"
(825 rounds saw a sparse levels Vector) against 0.201 s pinned (none did),
ending at 8.58 against 7.63 MiB. Nib's third note needed no change: the
docs never offer RSS as a measure of what an object holds.