Preserve fractional values when expanding written magnitudes

[Maya-Kid]

Problem

1.00000025 million and 100.000025万 were parsed as 1000000 instead of 1000000.25. After scaling an f64, the parser rounded values near an integer using a relative tolerance. At this magnitude the tolerance swallowed the genuine .25.

This also reaches persisted data: the authenticated attribute-adoption endpoint writes the rounded value when adopting a supported unbound typed value fact. Open-statement alignment is a separate path and is not claimed to be affected by that adoption test.

Change

Represent the existing magnitude words as decimal exponents and parse the validated decimal coefficient with that scale. This converts the scaled decimal directly to f64 instead of multiplying an already rounded float and guessing which remainder is noise. 9.2亿 still yields 920000000.

The exponent spelling is internal; the accepted input grammar, strict/leading parsing policies, currency/unit handling, finite-value check, and f64 return type remain unchanged. No dependency or database change. The temporary numeric string adds at most three bytes to the coefficient, so memory remains linear in the input length.

Validation

Linux with dedicated PostgreSQL/pgvector and UTOPIA_TEST_REQUIRE_DB=1:

• Baseline parser tests and authenticated adoption fail; the persisted value is demonstrably 1000000.0. The same tests pass after the fix.
• All 64 extract tests pass, including 1,344 generated signed decimal cases using an exact u128 decimal oracle, Chinese/English magnitudes, real fractions, integer controls, units, strict rejection, overflow, and long input.
• Authenticated adoption preserves .25, original value history, supersedes, source evidence, unit and audit records for both spellings.
• Format, workspace Clippy (-D warnings), workspace tests and build pass: 941 passed, 0 failed, 1 ignored live-public-HTTPS test.
• Unchanged frontend tree: reused the freshly verified T2 frontend checks (91 tests and build).

This corrects future conversions. It neither rewrites historical rounded values nor automatically undoes already adopted values on rollback. Full decimal precision and broad numeric normalization are outside this change.

Combined regression verification

All five independent fixes merge cleanly onto the same dev baseline. On the combined Linux branch, format, workspace Clippy, build and the full test suite pass (952 passed, 0 failed, 1 explicitly ignored live-public-HTTPS test). A shared authenticated RDF fixture verifies unbound values, subsecond history and explicit ontology links together in Turtle and JSON-LD. Removing each fix individually makes its regression fail again; restoring all fixes returns the full suite to 952 passing tests. No database migration or historical rewrite is included.