fix: accept retrievable builders as subqueries

[elpete]

Closes coldbox-modules/quick#226

Issue review

Recommendation: 9/10. A builder recognized by qb through its isBuilder contract should be usable in subquery positions when it exposes an underlying qb query through retrieveQuery(). This directly supports Quick without coupling qb to Quick types.

Reasons for:

• The reported public API flow is valid: a Quick scope is built once and reused inside a plain qb query.
• retrieveQuery() already defines the interop boundary; accepting the wrapper removes an arbitrary difference between it and asQuery().
• Centralizing conversion before snapshotting covers all snapshot-based subquery consumers while preserving qb isolation and CTE handling.

Tradeoffs:

• This broadens snapshotBuilder() from a nominal QueryBuilder type to a small structural contract.
• Invalid wrappers now reach the existing typed cloneBuilder() validation after attempted unwrapping.

Reproduction

With Quick next and the latest prerelease dependency (qb 14.0.0-beta.3), passing getInstance("User").where(...).asQuery().reselect("id") to a plain qb whereIn() reproduced the reported caster exception in QueryExecutor.snapshotBuilder(). The focused Quick bundle had 4 passes and 1 error before the fix.

Implementation

• Unwrap non-QueryBuilder builder wrappers through retrieveQuery() before cloning/snapshotting.
• Add a qb regression using a public whereIn() call and a retrievable builder fixture.
• Verify the exact Quick consumer flow executes and returns the expected rows.

Validation

• qb focused: 1 passed, 0 failed, 0 errors
• qb full suite: 3279 passed, 0 failed, 0 errors, 9 skipped
• Quick focused consumer bundle: 5 passed, 0 failed, 0 errors
• Quick full suite with this qb change: 496 passed, 0 failed, 0 errors, 3 skipped
• Formatting completed in both repositories
• git diff --check completed in both repositories