feat(vault-pinning): pin original blocks as a CAR so the pinned CID equals the Helia CID #48

Summary

Upload the blocks Helia already holds, instead of re-submitting the JSON for the provider to re-encode.

Estimated size: M

Motivation

A provider that re-encodes JSON can return a different CID than the one the user shared, which breaks citation.

Current state in this repo

• Adapters send JSON content to the provider's JSON-pin endpoint.
• The Helia integration overview reports that the returned CID can differ; this has not been reproduced in this repo yet.

Proposal

• Step 1: add a test or script that reproduces any CID mismatch for each provider.
• Step 2: export the DAG with @helia/car and upload it through the provider's CAR (or Pinning Service API) endpoint; verify each provider's supported endpoint first.
• Step 3: fail with a clear error if the CID the provider reports does not match the local CID.

Acceptance criteria

• For Pinata and Lighthouse, the CID returned after pinning equals the Helia CID, checked in a test.
• A mismatch is surfaced as an error, never silently recorded.
• The JSON path remains available behind a flag until CAR upload is proven.

Out of scope

• UnixFS and large files.

Technical notes and risks

• Coordinate with the broker work: if it lands first, upload from the browser to the broker route; otherwise start against the current adapters.

Dependencies

• Soft: feat(vault): server-side pinning broker routes #45 (uploads will move to the broker).

Testing plan

• Provider mocks plus one manual run against test accounts.

Part of #43. Ground rules for the content layer: no secrets in the repo, content-layer failures must never block or discard quantum execution, and tests and docs ship with every PR.