fix(sql): ORDER BY cursor keeps the source column types (#146)

[russimicro]

Fixes #146.

Problem

#136 materialises a single-table SELECT ... ORDER BY / DISTINCT / LIMIT
through build_memory_result(). That helper was written for system.*
catalogs and sp_* result sets, where every column is small and integral:

if (col.type == 'N') {
    f.raw_type = 11;
    f.type = ...::Integer;
    f.length = 4;            // the caller's length/decimals are discarded
}
...
if (rlen > 0xFFFFu) return Error{AE_INTERNAL_ERROR, 0, "result table record too large", tag};

The ORDER BY block does pass sc.decimals = fd.decimals, but the helper ignores
it. So over a user table:

• every N(n,d) comes back truncated — 12345.67 reads as 12345 — and values
  past 2^31 wrap. Silent, which is worse than the error;
• a wide table exceeds the 64 KB record cap and the statement fails. This is how
  we hit it: Select * From [articulo.dat] as a ... order by a.cnombreart on a
  187-field table returned ADSCDX/1012.

Change

Materialise from the source field descriptors: create a temp table from the
source structure (AdsCreateTable with the projected columns' real type, length
and decimals), copy the ordered rows in, close the live source, hand back a
cursor over the temp.

Every property #136 was after is kept:

• the cursor is static — INDEX ON over the result cannot reach the
  production .cdx;
• recnos are 1..N in result order;
• the column ACL is applied before the copy, so a restricted user's temp holds
  only permitted columns;
• no residue: the temp is registered against the cursor handle and
  AdsCloseTable removes its files, including any .cdx/.fpt an application
  built on the result. That is the one thing the memory table gave for free, so
  it is done explicitly here (materialised_cursor_temps /
  drop_materialised_cursor_temp).

The trade against a memory table is that the result lands on disk. For the ERP
workload that is the point — the application indexes and browses the result, and
it can be larger than is comfortable to hold in memory.

build_memory_result is untouched and still serves its catalog / sp_*
callers.

Verification

tests/unit/abi_sql_orderby_types_test.cpp — an N(12,2) column through
SELECT * ... ORDER BY, checking 10.50, 0.05 and 12345.67 round-trip.
Fails before the change (10, 0, 12345), passes after.

abi_sql_orderby_test.cpp (the #136 tests: materialised recnos, ORDER BY data,
source .cdx untouched) keeps passing.

Full suite on this branch (MSVC x64 Release): 1227/1235. The 8 failures are
pre-existing on main and unrelated — 6 × abi_pritpal_lock_test (remote
connect, the residual noted in the v1.8.37 release) and 2 ×
abi_server_fs_test whose teardown threw on remove_all because the temp
directory was held by another process on this machine.

This has been running the reporting ERP's ~60 SQL call sites in production
shape since we adopted v1.8.37.

[gemini-code-assist]

Caution

The consumer version of Gemini Code Assist on GitHub has been sunset. All code review activity has officially ceased.

[FiveTechSoft]

Integrated into main as part of the PR stack merge (9e7ac41). Cherry-picked onto post-CI-fix main, conflict-resolved (CHANGELOG / CMakeLists), and verified locally. Thank you @russimicro.