GeezerVison

`SelectOp._from_indexunary` reuses the IndexUnaryOp's `GrB_IndexUnaryOp`
rather than allocating a second one, and marked the borrowing typed op
`_owns_gb_obj_inst = False` so that only one side would free it. Nothing
kept the owner alive, though: `register_anonymous` drops the IndexUnaryOp
on the way out, so its typed op is collected and frees the handle while the
SelectOp is still pointing at it.

The result is a dangling pointer rather than a NULL one. `__del__` frees
through a synthesized cell, `ffi.new(f"{c_type_name}*", gb_obj)`, so
`GrB_*_free` clears that temporary and leaves the op's own `gb_obj` holding
the old address.

Reproduced at 6f1eb02:

    def _ne_thunk(x, i, j, thunk):
        return x != thunk
    sel = SelectOp.register_anonymous(_ne_thunk)
    gc.collect()
    Vector.from_coo([0, 1, 2], [1, 5, 9]).select(sel, 5).new()
    -> UninitializedObject

Whether it raises depends on whether anything happens to retain the
IndexUnaryOp. With `x > thunk` it survives, because a traceback caught
inside the per-dtype compile loop keeps a frame that references it.

Replace the per-instance opt-out with `_gb_obj_owner`, naming the owning
typed op. That suppresses our free and keeps the handle alive for as long
as we can reach it; disclaiming ownership without naming an owner is what
left the handle dangling. The opt-out being replaced was added in 6f1eb02
to stop a double free, so the sequence is leak, double free, opt-out,
dangling handle, and now an owned reference.

Read on its own, `_owns_gb_obj = True` says every TypedUserSelectOp frees
its handle. The ones `_from_indexunary` builds do not: they borrow the
IndexUnaryOp's `GrB_IndexUnaryOp` and set `_gb_obj_owner`, which suppresses
the free.

Worth a comment because the mistake is silent. Freeing from both sides is a
use-after-free, and a freed handle usually still reads as valid: with the
ownership removed, select kept returning correct results even after 30
fresh allocations churned the allocator. No test would catch it.