B-5: IPFS integration service for evidence and document storage

[KuchiMercy]

Summary

The metadata_hash field was recently added to the Escrow entity for IPFS agreement hashes (PR #185), but there is no general-purpose IPFS service for uploading and retrieving files. The dispute evidence workflow and agreement storage both need this.

Requirements

• Build an IpfsService that abstracts IPFS operations
• Support uploading files (images, PDFs, text) to IPFS via Pinata or web3.storage API
• Return the CID (Content Identifier) for each uploaded file
• Store CID references in the database linked to the relevant entity (dispute evidence, escrow agreement)
• Add a retrieval endpoint: GET /ipfs/:cid that proxies or redirects to the IPFS gateway
• Add an upload endpoint: POST /escrows/:id/evidence for dispute evidence
• Validate file types (allow: jpg, png, pdf, txt, doc) and enforce size limits (10MB per file)
• Pin uploaded files to ensure persistence

Acceptance Criteria

• Files can be uploaded to IPFS and a CID is returned
• CIDs are stored in the database linked to disputes/escrows
• Retrieval endpoint serves files via IPFS gateway
• File type validation rejects unsupported formats
• File size validation rejects files > 10MB
• Uploaded files are pinned on the IPFS pinning service
• Service handles upload failures gracefully with proper error messages

Context

• Metadata hash field: apps/backend/src/modules/escrow/entities/escrow.entity.ts (metadata_hash column)
• Dispute entity: apps/backend/src/modules/escrow/entities/dispute.entity.ts
• PR feat: add metadata_hash field to Escrow struct for IPFS agreement storage #185 established the pattern for IPFS hash storage

Rollout Phase

Phase 3 — Real-time & Disputes

Points: 150 (Medium)