Store a migration manifest (CID-to-piece receipt) on FOC at the end of every flow

[SgtPooki]

Description

A completed migration leaves no durable, self-contained record of what landed where. The mapping from source CID to piece CID, data set, piece id, and transaction exists only in the local migrate.db, which the PRD's "receipt"/"manifest" claims and the campaign runbook cannot point at.

Generate a migration manifest at the end of every flow (upload and the legacy pdp-submit path) and store it on FOC itself as one more piece in the same run:

• Content: per source CID — the piece CID it was packed into, raw size, sha256; per piece — each copy's provider id, data set id, piece id, and addPieces tx hash; run metadata — network, payer, source tag, tool version, timestamps; and every held-out or failed CID with its reason.
• Format: a CAR whose root is the manifest file, uploaded with withIPFSIndexing, so the receipt has its own IPFS CID and resolves from the providers like the migrated data. The manifest cannot list itself; its own CID and piece info go to stdout and migrate.db.
• Size: dominated by per-CID rows (~150–200 bytes each) — tiny for most runs, ~10 MB raw at 56k CIDs; a single small piece either way. Below a provider's advisory minimum piece size it warns and proceeds.

Impact

Closes the gap between the landing page's "receipt with transaction links" / "manifest mapping every IPFS CID" claims and what the tool produces, and gives report/verification (#73) a portable artifact instead of a local SQLite file.

Next steps

Implement for upload first (the campaign path), then pdp-submit. Decide whether the manifest lands in the existing data sets or a dedicated one per run.