Fix silent ID corruption caused by ColdFusion float precision limits

[zainforbjs]

Problem

ColdFusion represents all numbers as IEEE-754 double-precision floats, safely handling integers only up to 2^53-1 (9,007,199,254,740,991).
CockroachDB IDs exceed this limit. Any numeric coercion at the ColdFusion layer silently rounded ID values before they reached the database.

Observed behaviour:

writeDump(blog.id);       // string → 1151022801744953345  ✓
writeDump(val(blog.id));  // number → 1151022801744953344  ✗

No exception was thrown. WHERE clauses silently matched nothing.
UPDATE statements affected no rows. Lookups returned empty results.

Root Cause

ID fields were being coerced to ColdFusion numeric type through val(), int() binding in Wheels, and direct numeric
comparisons. All of these routes through CF's double, losing precision on any ID exceeding the safe integer range.

---

Error Example

// Original IDs
blogId = blog.id;        // string: "1151022801744953345"
numericId = val(blog.id); // number: 1151022801744953344 (precision lost)

writeDump(blogId);
writeDump(numericId);

// Query fails silently due to numeric precision loss
history = model("ReadingHistory").findOne(
    where="userId = #val(session.userID)# AND blogId = #val(blog.id)#",
    includeSoftDeletes=true
);

Problem: Using val() converts the ID to a double number, which cannot safely represent very large integers. The DB ID does not match the coerced numeric value → query returns nothing.

---

Fix

All ID field bindings changed string, keeping values as strings from CockroachDB through to the JDBC driver.
ColdFusion never interprets the value as a number.

• Removed all val() usage on identifier fields

Testing

• Verified ID values arrive at the database unchanged
• Confirmed WHERE clauses match correctly on affected queries
• No regressions on existing functionality

Notes

This is not a Wheels or CockroachDB bug. Any language using double as its default numeric type has this limit. Treating identifiers as strings at the application layer is the correct long-term pattern.

Fixed the above issue for the blog functionality. Others are in progress.