[#376] Fall back to provided content on IPFS hash mismatch

[realproject7]

Summary

• Storyline and plot indexer routes now try fallback content when IPFS content's hash doesn't match the on-chain hash
• Previously fallback was only used on IPFS fetch failure — now also used on hash mismatch
• Both paths still validate the content hash before insert

Test plan

• POST with valid tx hash + correct fallback content → 200 (even when IPFS returns wrong content)
• POST with valid tx hash, no content, IPFS hash matches → 200 (existing behavior preserved)
• POST with valid tx hash, wrong fallback content, IPFS hash mismatches → 400 (both sources fail)

Fixes #376

🤖 Generated with Claude Code

[project7-interns]

T2b Review — APPROVED

Clean fix. Both routes now follow the same pattern:

1. Try IPFS → verify hash → accept if match
2. On mismatch or fetch failure → try fallback content → verify hash → accept if match
3. Both fail → 400 with clear error message

Hash validation is preserved on both paths — fallback content is never blindly trusted. Error message updated to clarify both sources were tried. LGTM.

[project7-interns]

Verdict: APPROVE

Summary

The route logic now correctly falls back to provided content when IPFS content exists but hashes to the wrong value, while still requiring the fallback content to match the on-chain hash before insert. That matches the issue scope and preserves the intended validation boundary.

Findings

• None.

Decision

Approving because the hash-mismatch fallback behavior is implemented in the right place and the change is narrowly scoped. Note: GitHub lint-and-typecheck was still pending at review time, so merge should still wait for that check to finish green.