feat: add Query Builder value() and pluck()

[memleakd]

Description

This PR proposes adding two small Query Builder helpers: value() and pluck().

They cover a common case where we only need one column, not a full row or result set:

$email     = $builder->where('id', 1)->value('email');
$names     = $builder->orderBy('name', 'ASC')->pluck('name');
$namesById = $builder->pluck('name', 'id');

• value(): returns the selected column from the first matching row, or null if nothing matches.
• pluck(): returns one column as an array, and can optionally use another column as the array key.

These methods behave like other terminal Query Builder methods: they use the current builder state, reset it by default, and can keep it when $reset is false. They temporarily select only the requested column or columns, so existing select() clauses are not used.

I also added Model wrappers so soft-delete behavior is preserved when calling these through a model.

Raw SQL expressions are intentionally not accepted as column names. If users need an expression, select() with get() remains the right tool.

Tests cover SQL generation, reset behavior, query failures, live results, keyed pluck results, invalid column input, and Model soft deletes.

Checklist:

• Securely signed commits
• Component(s) with PHPDoc blocks, only if necessary or adds value (without duplication)
• Unit testing, with >80% coverage
• User guide updated
• Conforms to style guide

[michalsn]

I'm not convinced these helpers belong in the core API. value() and pluck() would be the first Query Builder methods that retrieve raw column data directly, bypassing the Result object. That is a meaningful change from the existing Builder design.

The Model wrappers are also questionable. Our current implementation already provides findColumn(), so pluck() introduces an overlapping way to retrieve a column with different semantics (and results). The new methods bypass normal Model behavior, such as model casting and model events.

I haven't looked into this in detail yet, but let's see what others have to say.

[memleakd]

Thanks, that's a very fair concern.

I still think there is real value in having these at the Query Builder level. In everyday app code, needing "just one value" or "this one column as an array" comes up pretty often, and right now it takes a few small but repetitive steps through get(), rows, arrays/objects, and manual extraction. value() and pluck() make that intent clear at the call site and remove a bit of glue code that many apps end up writing themselves.

I also agree that the Model side is a different story. The overlap with findColumn() and the difference in Model behavior makes that part less clear-cut. I'd be happy to remove the Model wrappers if that makes the proposal cleaner.

So for me the main value here is really the Builder DX: simple, explicit, easy-to-discover helpers for common scalar/list reads.

I'll wait for more feedback before changing anything, but I'm open to narrowing this to Builder-only if that feels like the right boundary. And if the team feels this does not fit the core Builder API either, I'm also okay closing it.