fix: generate unique deterministic CID per batch instead of hardcoded placeholder

[Kirtan-pc]

Summary

This PR fixes Issue #1236: frontend/src/app/add-batch/page.tsx:142 passes the literal CID "QmYwAPJhy5n2aBhajbN7yXq3TqK6Lj5ee2ov3333333333" to contract.createBatch(...) for every batch. Every on-chain provenance record stores an identical ipfsCID, destroying the value of batch-specific provenance data.

Changes

• frontend/src/app/add-batch/page.tsx (lines 138-155): Replaced the hardcoded CID string with a deterministic CID generated from the batch metadata. The function serializes batchId, cropType, quantity, farmerName, origin, harvestDate, and description into a JSON payload, hashes it with ethers.keccak256, and encodes the result as a Qm-prefixed CID. This produces a unique CID for each batch while remaining deterministic (same input = same CID), consistent with the backend's ipfsService fallback pattern.

Fixes #1236

Copilot Review Feedback

Other suggestions were evaluated but intentionally left unchanged because they are pre-existing issues outside the scope of Issue #1236:

Comment	Verdict	Reason
Upload batch metadata to real IPFS via Pinata from the frontend	Out of scope	Requires Pinata API keys on the client side (security concern); the backend already handles IPFS pinning via ipfsService for NFT metadata
Add a "pin to IPFS" button for manual upload	Out of scope	Pre-existing feature gap; introduces new UI flow and async UX beyond a targeted bugfix
Use SHA-256 instead of keccak256 for the hash	Out of scope	Keccak256 is already used throughout the project (ethers, smart contracts); consistency is more important than hash algorithm choice here

[vercel]

@Kirtan-pc is attempting to deploy a commit to the Nitya Gosain's projects Team on Vercel.

A member of the Team first needs to authorize it.