fix: make odata_describe report the type the reader binds

[jrosskopf]

Follow-up to #254, stacked on #255 (this PR targets that branch, so the diff shows only the describe change; retarget to main once #255 merges).

The defect

odata_describe() mapped the EDM type name alone, through the facet-blind ConvertEdmTypeStringToDuckDbTypeString. That is blind to everything the reader is not:

Property	reader binds	describe said
Edm.Decimal Scale="18"	DECIMAL(38,18)	DECIMAL
Edm.Decimal Precision="19" (no Scale)	DOUBLE	DECIMAL
Collection(Edm.String)	VARCHAR[]	VARCHAR
a complex type	STRUCT(...)	VARCHAR

So the one function whose entire job is to answer "what will this column be?" was free to disagree with the answer. It now goes through BuildLogicalTypeForProperty — the same mapping the reader uses.

Facets

The reported precision / scale / max_length had the matching defect: an absent facet was reported as 0, indistinguishable from a declared zero. Scale="0" against an absent Scale is exactly what decides DECIMAL(p,0) against DOUBLE, so the field a caller would consult to understand the type could not express the distinction. An undeclared facet is now NULL.

This is a visible change for anyone reading those three fields — worth noting in the release summary.

Verification

Live, against the public Northwind V4 service (its UnitPrice declares no facets):

-- before: describe said DECIMAL, odata_read bound DOUBLE
-- after:
odata_describe(...Products) -> UnitPrice  DOUBLE  precision=NULL scale=NULL
DESCRIBE SELECT UnitPrice FROM odata_read(...Products) -> UnitPrice  double

New test/cpp/test_odata_describe_types.cpp covers all four shapes plus the absent-vs-zero facet distinction against a local server — there was no C++ coverage of odata_describe at all before. The live test/sql/odata_describe.test still passes unchanged, as does the full suite (3189 assertions / 583 cases).

🤖 Generated with Claude Code

---

^{Need help on this PR? Tag @codesmith-bot with what you need. Autofix is disabled.}