Declare this launch's trust manifest

**Reading a launch reconciles it.** A launch is recorded as `awaiting_signature` and stays there until the chain says its token exists; there is no worker, so this read is what asks. When the launch is still `awaiting_signature` and the chain reports a deployed token, this route reads the creation transaction's receipt, decodes the factory's `TokenCreated` event, and records the token address — moving the launch to `live` before answering. The response is the reconciled row, and it is the same row a later read returns. The server still never signs and never broadcasts. It reads a receipt; the transaction was signed by the caller with their own wallet and reported through `POST /tx/{id}/submitted`. A launch that cannot advance yet is still a **200**, with the row unchanged and `reconcileReason` saying why: `receipt_pending` (the node answered, the receipt is not mined), `not_submitted` (the creation transaction has no reported hash yet), `venue_blocked` (this launch names a venue that cannot build a launch), or `chain_unreadable` (the node could not be reached; `reconcileDetail` carries its sentence). A launch waiting to be mined is a normal state, not a server fault, so this route does not answer 5xx for one. Poll again. A launch belonging to another user returns the same 404 as one that does not exist.