data ingest: add --append for existing destination tables (needs server-side support)

[LukasWodka]

Spun out of #70 when it closed. The silent-duplication bug is fixed on develop (#149): re-ingesting into an existing table now stops with exit 6, and --overwrite (teardown + re-ingest) is shipped. --append was deliberately NOT shipped because it can't be done client-side:

1. The ingestor has no append mode — DuplicateValidator fails on a non-empty destination directory, and the staging/ingest path assumes a fresh table. Appending needs defined server-side semantics first (duplicate-key handling: skip / replace / error).
2. No Job↔table link exists, so the CLI can't guard against appending while another ingest run into the same table is still in flight — a required safety rail before append is offered.

Scope: server-side append semantics in tracebloc/data-ingestors, then the CLI flag + preflight wiring. Until then, exit 6 + --overwrite cover the known workflows.

Parent QA epic: #67. Context: #70, PR #149.

[LukasWodka]

Closing as obsolete — will not build (decided 2026-07-11).

--append (adding data in place to an existing dataset) breaks dataset integrity and reproducibility, which are foundational to the platform: a dataset is the fixed basis for its use cases and for training. If data is appended over time, a model trained against an earlier state of the dataset can no longer be compared to one trained after the append — the leaderboard stops being a fair benchmark and results stop being reproducible.

This traces back to a customer request that was really a misunderstanding of how the platform works — datasets are immutable snapshots, not mutable buckets. The real workflows are already covered: --overwrite (replace a dataset wholesale) and ingesting a new, separate dataset. If incremental growth is ever genuinely needed, the correct shape is dataset versioning (a new immutable version), not in-place append — which would be a fresh, properly-scoped ticket at that point.

No code was built for this. Retiring.