Unify the schemas of many files

Constraints

1. 1A field's type must hold every value in every file that declares it. Compare type names after stripping and lowercasing.
2. 2These promotions are safe, and they compose: int32 to int64, int32 to float64, int64 to float64, float32 to float64, and date to timestamp.
3. 3Any other disagreement is a conflict. The field is left out of the schema entirely and reported with every type that was declared for it, sorted.
4. 4Promotion accumulates across files. Three files declaring int32, int64 and float64 unify to float64.
5. 5A field declared by some files and not others is fine — it reads as null in the rest — but report it under partial_fields.
6. 6A file with no readable schema is skipped and is not counted when deciding whether a field is partial.
7. 7Return the schema as a field-to-type mapping in sorted field order, alongside conflicts and partial_fields.

Worked example

The amount column is int64 in January, float64 in February and March, and float32 in April. Unifying pairwise from the start gives int64, then float64, then float64 again — one type that reads every file. Taking the last file's declaration would give float32, and the January values that do not fit in 24 bits of mantissa would be read back subtly wrong, with no error anywhere. The note column is string in January and int64 in March. There is no type that reads both, and there is no honest default: choosing string means the March values are stringified, choosing int64 means January fails to parse. Reporting it as a conflict and excluding it is the only answer that does not silently corrupt one of the two months, and it is a decision a human has to make.

What this tests

Type promotion as a lattice rather than a preference order, and the discipline to refuse rather than guess. The reason a lakehouse table format keeps a schema at all is precisely that inferring one per file produces exactly this problem.