A successful upload receipt prevents a replacement recording from being sent by record --sync

## Problem

After a passage has been uploaded once, re-recording it offline with `record --redo ` does not make it pending again. A later `record --sync` treats the old successful receipt as proof that the replacement take is already on the server.

`CorpusUploadOutbox.pending()` filters recordings solely by passage IDs with an `.uploaded` receipt. The receipt has no recording revision, timestamp or content identity to compare with the current take. `TranscriptionCorpusStore.save()` replaces the local take but does not invalidate the receipt. `RecordCorpus` supports `--redo` without `--upload`, so this is an ordinary supported workflow.

## Verified evidence

Main `5c310667cd35c44abd8bbd26c19b0905471287b4`, unchanged production outbox and recording store, real temporary files and a simulated uploader:

1. Save a take for the existing `en-standup` passage and send it successfully.
2. Save a replacement with the same passage ID, a later `recordedAt`, and different audio bytes.
3. Ask for pending recordings and flush.

Actual: `pending=0`, total uploads remain `1`, and the uploader still has the original bytes. Expectations that the replacement becomes pending and is sent both fail. The existing 14 outbox tests pass but do not cover replacement after success.

The probe uses synthetic bytes to test scheduling/persistence; it does not record a microphone or contact the backend.

## Impact and acceptance criteria

The local corpus and remote corpus silently contain different takes, and `record --sync` can report that everything has been accepted while the replacement was never sent.

- Tie settled receipts to the current recording revision/content, or durably invalidate them when a take is replaced.
- Ensure offline redo followed by sync uploads the replacement; unchanged takes should remain settled.
- Cover restart between saving a replacement and syncing, plus compatibility with existing receipts.
- Define the outcome when replacement happens during an in-flight upload so its old success cannot settle a newer take.

Relevant code: `Sources/UttrflowEval/CorpusUploadOutbox.swift` (`pending`, `send`, `UploadReceipt`), `Sources/UttrflowEval/TranscriptionCorpusStore.swift` (`save`), and `Sources/uttrflow-eval/RecordCorpus.swift` (`--redo`, `record`, `flush`).

Start with Sources/UttrflowEval/CorpusUploadOutbox.swift, especially pending, send, and UploadReceipt, then inspect TranscriptionCorpusStore.save() and RecordCorpus.swift handling of --redo and flush. Extend the existing 14 outbox tests to cover replacement, restart, existing receipts, unchanged takes, and replacement during an in-flight upload. Done means offline redo followed by sync uploads the replacement without resending unchanged takes.

Written by the indexing model from the issue text.