fix: upload CLI defaults to replay=True, add --no-replay opt-out

[colombod]

Problem

The upload CLI never passed ?replay=true to the server. The server's in-memory
idempotency cache (7-day TTL) silently dropped session:start events on re-upload,
leaving Session nodes without started_at. This caused re-uploaded old sessions to
appear in Neo4j without their original timestamps.

Changes

uploader.py — run_upload() gains replay: bool = True. When True (the
default), every POST is sent with ?replay=true, bypassing the server-side cache.
Set to False to restore the old deduplication behaviour.

cli.py — --no-replay flag added. Default is replay=True (no flag needed).
_DETAILED_HELP IDEMPOTENCY section rewritten to accurately describe the new default:
cache is bypassed, Neo4j idempotency is provided by MERGE + SET n += row.props.

Why --no-replay instead of --replay

The upload CLI is always a deliberate replay of existing JSONL data. There is no
scenario where silently skipping events is the right default. --no-replay is the
explicit override for the rare case (e.g. uploading a live in-progress session).

Verification

• 168/168 tests pass (uv run pytest -q)
• Ruff: clean — All checks passed!
• Pyright: 0 errors, 0 warnings, 0 informations
• Red-green confirmed: test fails with assert None == {'replay': True} on main,
  passes on this branch
• No Neo4j operations in any changed file

[bkrabach]

Reviewed. Diagnosis (7-day cache silently dedup'ing replays so Session.started_at goes missing) and fix (default replay=True, opt-out via --no-replay) both make sense. One pre-merge ask:

Could you link or quote the server-side /events POST handler to confirm ?replay=true triggers only idempotent Neo4j operations? The PR description states Neo4j writes are MERGE + SET n += row.props. If that's universally true across all event types — no counters, no list appends, no audit log inserts, no side-effecting webhooks — then replay=True by default is safe.

This is a server-repo question, not a critique of this PR. If the server is pure-MERGE: approve immediately.

(The new default has no interaction with the real-time hook path or CR-1 parent_id propagation — the upload CLI is offline-batch only.)

[colombod]

Verified against the server repo (amplifier-context-intelligence). The server is pure-MERGE — here's the evidence:

All Neo4j writes go through neo4j_store.py:_flush_body():

# Nodes (line 402-404)
"UNWIND $rows AS row "
"MERGE (n:Session {node_id: row.node_id, workspace: row.props.workspace}) "
"SET n += row.props"

# Non-session nodes (line 411-413) — same pattern
"MERGE (n {node_id: row.node_id, workspace: row.props.workspace}) "
"SET n += row.props"

# Edges (line 475-479) — same pattern
"MERGE (src)-[r:{edge_type}]->(dst) "
"SET r += row.props"

SET n += row.props on an existing node updates properties in place — no duplicate nodes, no counters, no list growth in Neo4j.

Label patches (lines 426, 440, 450): SET n:Label / REMOVE n:Label — idempotent label assignments, not additive writes.

In-memory counters (registry.py:66, iteration.py:74): events_processed += 1, iteration_count += 1 — these are in-memory Python state on the worker, never written to Neo4j, and reset on server restart. They do not accumulate across replay runs.

No webhooks or external HTTP calls in the handler chain — grepped handlers/**/*.py for httpx, requests, urllib, aiohttp: zero matches.

Blob store (blob_store.py:147): path.write_text(json.dumps(value), encoding='utf-8') — overwrites the file, not appends. Idempotent on replay.

One edge case to be aware of: neo4j_store.py:83-84 has a DETACH DELETE duplicate path that fires when concurrent workers race to MERGE the same node. This is a safety cleanup that leaves exactly one node — idempotent by design, not an audit log.

Conclusion: The server is pure-MERGE for all durable state. replay=True by default is safe.