fix(c/driver/sqlite): preserve REAL precision on string inference

[efegokdemir]

What

During mixed-type inference, the finite REAL conversion now uses SQLite’s locale-independent %!.17g formatter. This preserves binary64 round-trip precision and renders integral REAL values with .0; non-finite values retain the existing SQLite formatting.

Closes #4862

[Copilot]

🟡 Changes recommended

The new formatting produces invalid output under decimal-comma locales.

1 open finding

• Use locale-independent floating-point query formatting · New

What changed in this PR

Preserves binary64 precision when SQLite REAL values are inferred as strings.

Changes:

• Formats finite doubles with 17 significant digits.
• Retains .0 for integral REAL values.
• Adds round-trip precision tests for both conversion paths.

File	Description
c/​driver/​sqlite/​statement_reader.c	Updates REAL-to-string formatting.
c/​driver/​sqlite/​sqlite_test.cc	Adds precision regression coverage.

🧠 Review effort: Balanced

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[Copilot]

🟢 Approval recommended

The implementation addresses both conversion paths and includes focused regression coverage.

0 open findings

1 resolved since last review

• Use locale-independent floating-point query formatting

🧠 Review effort: Balanced

[lidavidm]

I don't love this; it smacks too much of using AI to apply patches on patches to "fix" an issue, especially now that we're futzing with locales inside the conversion path.

Are we sure that SQLite's printf isn't consistent with what it outputs when you request a string from a statement?

[lidavidm]

Also, why does preserving the .0 matter so much?

[efegokdemir]

I used AI assistance. I’ve switched to SQLite’s %!.17g formatter, which keeps locale-independent, round-trippable REAL text and preserves .0 for integral values. The SQLite test binary passed: 129 passed, 16 skipped.