fix(model): BoxLang + Oracle finders return oracle.sql.TIMESTAMP objects instead of CFML dates #3719

On BoxLang + Oracle, model finders return datetime/timestamp columns as raw oracle.sql.TIMESTAMP driver objects instead of CFML dates. This was found while fixing #3715 (PR #3718): bulkOperationsSpec read found.createdAt[1] from findAll() and Len() threw Cannot determine length of object of type oracle.sql.TIMESTAMP.

User impact

I checked this against a real oracle.sql.TIMESTAMP on BoxLang (bx-oracle driver), local container:

So on BoxLang + Oracle, any app that formats, compares, outputs, or JSON-renders a timestamp column from a finder breaks. That covers createdAt/updatedAt in views and renderWith() APIs.

Existing workarounds (to remove with the fix)

• vendor/wheels/tests/specs/model/propertiesSpec.cfc (~lines 111, 126 and the helper near 759) special-cases IsInstanceOf(x, "oracle.sql.TIMESTAMP") and calls timestampValue().
• vendor/wheels/tests/specs/model/bulkOperationsSpec.cfc (after fix(oracle): run bulk inserts as a PL/SQL block so BoxLang asks no keys #3718) asserts through $normalizeDbTimestamp() instead of reading the column directly.
• Framework-internal readers already route through $normalizeDbTimestamp() (Oracle legs: timestamp round-trip, RateLimiter database storage, applied_at and belongsTo failures + invalid Oracle URL on Lucee #3649), which handles this shape correctly on BoxLang. The gap is the finder results handed to app code.

Proposal

Normalize datetime-typed columns in finder results, so every engine hands app code a CFML date. $normalizeDbTimestamp() already exists for this. Apply it only to columns the model's property metadata marks as datetime/timestamp, and only when a value is not already a date, so the cost on engines that already return dates stays small. With the fix, remove the spec workarounds above so the specs assert the real contract.

Not fixed yet: the 4.1.1-or-follow-up decision is pending with the maintainer.