Remove key atomization in SchemaUtils.to_typemap/2

[ruslandoga]

Sort of related: https://erlef.org/blog/eef/atom-exhaustion -- but I'll also check if it helps perf.

[ruslandoga]

Off-topic, but is this actually the desired behaviour? The produced string is very different.

iex(1)> "yþy" <> <<0>>
#==> <<121, 195, 190, 121, 0>>
iex(2)> <<0xFF, 0xFE, 0xFD>>
#==> <<255, 254, 253>>

[djwhitt]

I think it's worth cleaning up the dead to_typemap/1 metadata path as part of this PR.

• The metadata variant (lines 75-118) and decode_until_valid!/2 are unreachable from production code. The only caller that fed user-supplied keys into to_typemap/1 was BigQuerySchemaChange.validate, and perf: rewrite BigQuerySchemaChange.validate as single-pass walk #3489 rewrote that to walk the body directly with to_string/1 — no intermediate typemap, no atomization, no canonical form needed for keys. Invalid-UTF-8 keys in log payloads now just miss the schema_flat_map lookup and pass through as unknown fields, which is the same effective outcome the old code produced.
• A git grep to_typemap across lib/ and test/ confirms zero non-test callers of the metadata variant; the only consumer is schema_utils_test.exs itself.
• The new "yþy" assertion in this PR is documenting behavior of dead code.

Brief history for context on why the path is there in the first place:

• 85dfb6972 (Jan 2020) introduced to_typemap/1 with String.to_existing_atom, assuming field-name atoms were already minted earlier in the pipeline.
• 9d7470435 (Sep 2020, "fix the schema utils to not existing atom bug") swapped that for String.to_atom after the assumption broke on novel payload fields — trading the crash for unbounded atom growth.
• e08caec35 (Dec 2020, "fix the utf8 encoding bug") added decode_until_valid!/2 after customers sent Latin1-encoded field names (the fixture in that commit is the Portuguese "Código de Rastreio" mojibake). String.to_atom requires valid UTF-8, so the decoder fallback + Unicode.unaccent existed solely to produce a string the atomizer would accept.
• 62aaa6ef0 (perf: rewrite BigQuerySchemaChange.validate as single-pass walk #3489, May 2026) rewrote the validator to skip the intermediate typemap entirely. That severed the only production call site that fed user-supplied keys into to_typemap/1, which means the whole "make an atom out of arbitrary bytes" chain no longer has a job to do.

Suggested steps to do this:

• Delete the to_typemap/1 metadata clauses in schema_utils.ex (lines 75-118 on this branch).
• Delete decode_until_valid!/2 (lines 120-136).
• Delete not_empty_container?/1 (lines 138-148) if there are no other callers — looks like there aren't.
• In schema_utils_test.exs, drop the describe "to_typemap/1" block's metadata-input cases. Keep the BigQuery-schema test ("BigQuery schema field names are preserved as strings") since it covers the live variant.

[ruslandoga]

I've opened a separate PR to remove to_typemap/1: #3539

This PR will focus on removing atomization from to_typemap/2.