perf: fuse to_bigquery_column_spec into a single binary walk

[djwhitt]

Summary

Replaces the five-stage to_bigquery_column_spec/1 pipeline (strip_bq_prefix → dashes_to_underscores → alter_leading_number → alphanumeric_only → enforce_field_length) with a single binary walk that tracks the dash/non-alnum flags inline and detects the reserved-prefix and leading-digit cases up front. Each rule still contributes at most one leading underscore; the digit rule is suppressed when a prefix or dash has already prepended, preserving the order of the original pipeline.

Stacks on top of #3489.

Combined perf delta (LogEvent.make median wall time, edge log fixture)

• pre-perf: rewrite BigQuerySchemaChange.validate as single-pass walk #3489 baseline: 77.25 µs
• after perf: rewrite BigQuerySchemaChange.validate as single-pass walk #3489 single-pass validate: 57.75 µs (-25%)
• after this PR fused column-spec walk: 25.71 µs (-67% combined, -55% from the perf: rewrite BigQuerySchemaChange.validate as single-pass walk #3489 baseline)

Wall time roughly halves on every benched scenario (edge log + otel trace, with/without copy/kv/drop transforms). Reductions stay flat to within ±5%, which is the strongest sanity check that the new walk isn't skipping work — the win is almost entirely the eliminated :re.run/3 and :binary.match/2 NIF round-trips, which don't count toward reductions but consume wall-clock time. The previous bench's per-call profile attributed ~20% to the column-spec pipeline; halving the end-to-end wall says the NIF crossing overhead per key was larger than tprof could attribute.

Captured snapshot is appended to test/profiling/log_event_make_bench.history.exs against SHA 9760d277d.

Quirky behavior preserved (worth a careful look)

The legacy alphanumeric_only step used ~r/\W/ without the unicode modifier. PCRE in byte mode classifies bytes using a Latin-1 word-character table, not ASCII-only [a-zA-Z0-9_]. That means:

• bytes 192..214, 216..246, 248..255, plus the singletons 170 (ª), 181 (µ), 186 (º) are treated as word characters and pass through unchanged
• byte 215 (×) and 247 (÷) are non-word
• bytes 128..169, 171..180, 182..185, 187..191 are non-word

So a UTF-8 "é" (bytes <<0xC3, 0xA9>>) becomes <<?_, 0xC3, ?_>> after the rule fires — only the trailing 0xA9 is replaced; 0xC3 is kept verbatim because PCRE considers it a Latin-1 letter byte. This is almost certainly not what the original author intended, but it has been the observable behavior shipping to BigQuery, so column names already exist that include those bytes. Changing it would silently rename columns and break downstream tables.

The new walk replicates the PCRE table exactly (see the third walk_bq_key/4 clause) so non-ASCII keys produce identical column names. If we ever want to switch to a sensible UTF-8-aware classification (or strict ASCII), it should be a deliberate, separately benchmarked migration with a migration plan for the affected columns — not a quiet side-effect of this PR.

Tests

• test/logflare/logs/ingest/ingest_transformer_test.exs gains a new describe ":to_bigquery_column_spec fused pipeline" block (~18 tests). These were authored against the legacy implementation and pass against both — they're a strict characterization layer covering each rule in isolation, cumulative _ prepending, leading-digit suppression when a prefix or dash already prepended, pass-through cases (atom/int/empty-string keys, already-valid keys), the PCRE Latin-1 word quirk on multibyte input, and the 128-byte field-length boundary including prefix-induced truncation.

Test plan

• mix test test/logflare/logs/ingest/ingest_transformer_test.exs
• mix test test/logflare/log_event_test.exs
• mix lint.diff
• mix test.typings
• Eyeball the PCRE Latin-1 word table comment + matching guard clauses against the byte enumeration in the PR description

🤖 Generated with Claude Code