fix(adt): a decimal-less numeric wider than int32 no longer reads back as 0

[russimicro]

adt_spec_for() maps every DBF N(n,0) to ADS_INTEGER, a 4-byte int32 capped at 2,147,483,647. Anything wider is destroyed on the way in: an N(19,0) holding 5000000000 comes back as 0 — not rounded, zero, and nothing anywhere signals the loss.

Real schemas reach past that ceiling without being unusual: a credit limit N(16,0) in a soft currency, or the N(19,0) money columns of a tax-reporting table carrying yearly totals.

Narrow fields keep using INTEGER — 9 digits top out at 999,999,999, which always fits, and the column stays half the size of a DOUBLE. Wider ones become DOUBLE, exact for integers up to 2^53 (~9.0e15).

case 'N':
    if (f.dec > 0)      return {10, 8, f.dec, false};  // DOUBLE
    if (f.length <= 9)  return {11, 4, 0,     false};  // INTEGER
    return                     {10, 8, 0,     false};  // DOUBLE

N(n,d) with d > 0 already mapped to DOUBLE and keeps storing 0 decimals in its field descriptor — that is what the real engine does, and stamping the Harbour decimals there made it reject the table as corrupt (7016). Unchanged here.

Measured before/after on the same table, values read back after closing and reopening:

field	before	after
N(12,0) = 123456789012	0	123456789012
N(18,0) = 123456789012345678	0	123456789012345700
N(19,0) = 1234567890123456789	0	1234567890123457000

New test abi_adt_wide_numeric_test.cpp pins both halves of the contract: N(9,0) must stay INTEGER, and the wider ones must round-trip values above the int32 ceiling.

Suite: 1208/1226 — the 18 pre-existing failures of origin/main on this machine and nothing else, confirmed over three runs.

[gemini-code-assist]

Caution

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