[Bug] Indexer Should Fall Back When IPFS Content Hash Mismatches On-Chain Hash

[realproject7]

Summary

Running the mainnet E2E verification from plotlink-contracts#29 exposed an API bug in the PlotLink indexer routes. The E2E test uses dummy CIDs that can resolve to real but unrelated IPFS content. When that happens, the indexer fetch succeeds, computes a hash mismatch against the on-chain content hash, and returns 400 instead of falling back to the provided content.

Problem

Current behavior in storyline/plot indexing routes:

1. Fetch content from IPFS
2. Compute keccak256(ipfsContent)
3. Compare with on-chain hash
4. If mismatch, return 400

This prevents the fallback content path from running when the CID exists but resolves to wrong content.

Scope

Update the relevant PlotLink indexer API routes so they can fall back to provided content not only when IPFS fetch fails, but also when IPFS fetch succeeds and the fetched content hash does not match the on-chain hash.

Acceptance Criteria

• Storyline indexing can fall back to provided content after IPFS hash mismatch
• Plot indexing can fall back to provided content after IPFS hash mismatch
• The fallback path still validates that provided content matches the on-chain hash before insert
• The E2E verification for issue plotlink-contracts#29 can proceed past the current 400 hash-mismatch failures
• PR includes the correct original issue number in the title

Notes

• T3 reported the current failing CID as QmYwAPJzv5CZsnA625s3Xf2nemtYgPpHdWEz79ojWnPbdG, which is a real CID resolving to unrelated content
• Option 1 (API fix) was identified as the cleanest approach because it improves route resilience generally, not just for this test data