fix(string): a STR view keeps only the bytes it points at

[ser-vasilich]

Bug

The descriptor views introduced for substr and if over STR columns pinned more than they used. An if whose two sides come from different pools — including two columns of one table under a where: that keeps a few rows — copied both whole parent pools into the result (a 10k-row result out of 500k rows carried the two columns' 43 MB); the eager arm did the same for an unfiltered if. A substr with a per-row start or length retained the parent pool even when every result fitted inline and nothing pointed into it.

Fix

• if builds a pool of exactly the chosen rows' bytes whenever the sides come from different pools, a pooled scalar is involved, or the rows keep a small share (under an eighth) of one shared pool. One shared pool whose rows keep most of it is still pointed into, so a derived-key expression over one column stays copy-free.
• A substr view whose descriptors are all inline drops its pool reference; one that points into the pool stays a view.

test/rfl/strop/str_view_pool_compact.rfl pins the retained bytes through direct-bytes: an if under a where over two columns, over two substring views, with a pooled scalar side, the eager if against the two-pool sum, and an inline substr view outliving its table.

[singaraiona]

The case labelled “eager if” in str_view_pool_compact.rfl still takes exec_if_selected: STR is excluded from the eager shortcut at pivot.c:892, and both column scans support selected evaluation. This leaves the separately changed eager two-pool offset/copy path without demonstrated regression coverage. Please add a case that demonstrably reaches that path (a scalar BOOL condition is one candidate), checking values after source release and pool retention with serial and multiple-worker execution; also correct the current eager-coverage label.