Per-table dedupe id_field (+ fix cross-table dedupe keyspace collision)

[EricAndrechek]

Area: dedupe — gap + latent correctness bug · found via WaveHouse-Stats dogfooding

Expected: each table dedupes on its own natural key, in its own keyspace.

Actual: two problems with the single global dedupe key:

1. One global id_field name applies deployment-wide (internal/config/config.go:105-108) — every table that wants dedupe must carry an identically-named column.
2. Shared keyspace (latent bug): CheckAndMark keys Pebble on the raw id value with no table namespace (internal/dedupe/embedded.go:29, key := []byte(eventID)). Equal id values across two different tables collide — the second is silently dropped as a "duplicate." Only bites when ids aren't globally unique across tables (e.g. per-table sequential ids), but it's silent data loss when it does.

Impact (Stats): we standardize on globally-unique event_id, so the collision doesn't bite us today — but it's a sharp edge for any multi-table deployment, and the single id_field forces a naming convention on every future table.

Scope: namespace the dedupe key by table (fixes #2 regardless), and allow a per-table id_field (fixes #1). The keyspace fix is the more urgent half.

Related: #219, #220, #221.

---

From WAVEHOUSE-FEEDBACK.md (WaveHouse-Stats dogfooding); validated by code-read against 0f8826c on 2026-06-04.

[EricAndrechek]

Cross-linking #370 — it's a concrete instance of item 2 here (the shared, un-namespaced keyspace).

A present-but-null id_field dedupes on the literal string "<nil>" (fmt.Sprint(nil)), and because the key has no table prefix (internal/dedupe/embedded.go:29) that collision is global across every table — the same root cause as the cross-table keyspace bug in item 2. So namespacing the key by table fixes the cross-table dimension of #370 too; #370 additionally needs null/missing treated as "no id" in processRecord.

Flagging so the keyspace change is coordinated across both.