pin_git_object records a fabricated CID when /api/v0/add returns no Hash #452

pin_git_object (crates/gitlawb-node/src/ipfs_pin.rs) parses the NDJSON response from POST /api/v0/add and takes the last line carrying a Hash. When no line yields one (empty body, malformed NDJSON, a backend with a different response schema), it falls back to Cid::from_git_object_bytes(data), the CID it computed locally.

That records an address the backend never confirmed stored. Above the backend's chunk threshold (262144 bytes on Kubo) it is guaranteed wrong: the add goes out with raw-leaves=true, so large payloads land as chunked leaves under a dag-pb root, and the whole-object raw CID is not a stored block. Every later /api/v0/cat on it 500s. Since the result lands in encrypted_blobs.cid, get_encrypted_blob fails on every fetch of an affected envelope and mirrors retry it on each sync.

Reproduced against Kubo v0.43.0: a 200 add response of {"Name":"object","Size":"19"} returns Ok(<locally computed raw CID>) instead of an error.

Expected: a 200 without a usable Hash is an add failure. The returned hash stays authoritative; above-threshold adds legitimately return the dag-pb root CID, so the fix should not require the returned Hash to equal the locally computed raw CID.