Evaluate reference counting for col_rel_t lifetime management

[justinjoy]

Context

wirelog's col_rel_t currently uses a single-ownership model: each relation is either pool-owned or heap-allocated, and col_rel_destroy unconditionally frees data, merge_buf, and timestamps. Ownership transfer is tracked via the owned flag in eval_stack_push.

As the system grows more complex (materialization cache sharing, K-fusion worker copies, incremental view maintenance), the question arises whether a reference-counted lifetime model (similar to GLib's GObject with g_object_ref/unref) would be more maintainable and less error-prone.

---

Current pain points

1. Materialization cache: col_mat_cache_insert takes ownership of the relation, then a borrowed (non-owned) reference is pushed to the eval stack. This implicit shared reference is not tracked — if the cache evicts the entry while a stack reference is live, we get a use-after-free.

2. K-fusion COW: Workers currently copy entire relations to avoid shared mutation. With refcounting, read-only sharing would be zero-copy until a write triggers a copy (true COW).

3. Pointer swap (issue DOOP benchmark OOM: unbounded memory growth in recursive evaluation loop #218): The recent merge_buf/data swap optimization works because ownership is strictly 1:1. If multiple consumers held references to rel->data, the swap would invalidate them. Refcounting would formalize this invariant.

---

Arguments for refcounting

• Eliminates implicit sharing bugs: Every shared reference is explicitly tracked.
• Enables zero-copy sharing: K-fusion workers, cache consumers, and delta subscribers can share relation data without copying.
• GLib precedent: Well-understood pattern in C ecosystems. g_object_ref/unref with release callback is battle-tested.

Arguments against (for now)

• C11 manual management: No destructor or RAII — every ref must have a matching unref. Missed unref = memory leak; double unref = UAF. Current single-ownership is simpler and safer.
• Orthogonal to OOM: The DOOP OOM (issue DOOP benchmark OOM: unbounded memory growth in recursive evaluation loop #218) is caused by data volume (join output explosion), not lifetime management. Refcounting doesn't reduce peak memory of a 50M-row join result.
• Threading complexity: Refcount must be atomic (_Atomic uint32_t) for K-fusion workers. Adds contention on hot paths.
• Migration cost: Every col_rel_destroy call site needs audit; every eval_stack_push(rel, owned) becomes col_rel_ref(rel) / col_rel_unref(rel).

---

Questions for discussion

1. When would refcounting become necessary? Is there a specific feature (e.g., multi-consumer views, streaming output) that would tip the balance?
2. Scope: Should refcounting apply only to col_rel_t, or also to arrangements and cached state?
3. Alternative: Would a simpler arena/epoch-based reclamation (free all temporaries at epoch boundaries) be sufficient without full refcounting?

Related: #218 (DOOP OOM), materialization cache in ops.c