feat(engine-contract): write capabilities, ensure_unique_key, conformance suite (contract 0.8.0)

[carolsimone]

Adds opt-in engine write capabilities and a reusable conformance suite so warehouse adapters share the same append and upsert requirements.

• TableIntrospection, AppendCapable, UpsertCapable, and LiveColumn live in continuo_engine_contract.port. Declaring a capability requires implementing its abstract methods. UpsertCapable.upsert checks key uniqueness before calling the engine's _upsert.
• continuo_engine_contract.keys provides ensure_unique_key and DuplicateKeyError. Floating-point primary-key columns are rejected because Arrow grouping does not match warehouse equality for signed zero.
• WarehouseAdapter.ensure_table accepts an optional keyword-only primary_key.
• continuo_engine_contract.testing.conformance ships reusable pytest classes for adapter integration suites, with adapter and schema fixtures. Pytest and PyArrow are optional dependencies under the testing extra. The contract suite exercises these classes against an in-memory reference adapter and broken-adapter controls; the packaging test checks the wheel includes the testing package.
• CLAUDE.md requires real-engine conformance checks in CI for declared capabilities and shared coverage for new engine-independent contract requirements. Engine-specific behavior stays in adapter tests.
• The contract version is 0.8.0, with workspace and image requirement pins aligned.

Validation: 163 contract tests passed in Docker; Ruff and mypy passed. The targeted Continuo Python release and execution end-to-end tests passed against the existing local stack, including five execution subtests. Independent review found no actionable issues.

[carolsimone]

High · bug: append/upsert still execute as replace (inherited from #74)

Location: continuo_python_runtime/contract/loader.py:290–299. This is inherited from the prerequisite branch, so it is posted here as a review note rather than attached to this PR's diff.

The loader accepts append and upsert, but harness.run_node() still unconditionally calls ensure_table() followed by load(), whose contract is to replace the table's contents. In reproductions using validated nodes and an in-memory adapter initially holding id=99, both modes returned success and left only id=1. Adapters without either opt-in capability also reach this path.

Until the capability-specific write dispatch is implemented, reject these modes in the harness before running the script or writing anything. Otherwise an accepted append/upsert contract can silently delete existing rows.

[carolsimone]

High · bug: signed-zero keys bypass the uniqueness check

Arrow groups 0.0 and -0.0 separately. Consequently ensure_unique_key(pa.table({'id': [0.0, -0.0]}), ['id']) returns successfully even though the warehouse compares these keys equal.

This input also passes conform() for a non-nullable DOUBLE PRECISION key. In an in-memory DuckDB reproduction, a MERGE into an empty table inserted both rows, and SQL GROUP BY id reported one key with count 2. The template method therefore allows duplicate warehouse keys to reach _upsert, violating the invariant this guard is meant to enforce.

Normalize floating key equality (including signed zero) before grouping, or reject unsupported floating key types, and add a regression test.

[carolsimone]

Fixed in b47e4da. ensure_unique_key now rejects floating-point key columns (halffloat/float/double) with a ValueError before grouping. Normalizing signed zero would need pyarrow.compute, but the contract package keeps pyarrow out of its runtime imports (sqlglot-only), so rejection is the right option — and ensure_unique_key is the single enforcement point the UpsertCapable.upsert template runs for every engine. Regression tests cover 0.0/-0.0, float32, a composite key with one float column, and that decimal128 keys still pass.

[carolsimone]

The append/upsert-as-replace risk is now guarded: c587b88 (on the R1 base branch feat/write-modes-contract-fields) rejects any non-replace mode_type in run_node before the script runs or anything is written, with a test proving no write happens for either mode. It is an interim guard that R6 removes when it lands the per-mode _WRITERS dispatch + capability check and the row-preservation end-to-end tests, all before the single v0.9.0 tag. The signed-zero uniqueness hole is fixed in b47e4da.

[carolsimone]

Why do we have tests within this module? This is the implementaion module.