feat: Implement content-based offer IDs with SHA-256 hashing

- Added hash-id.ts utility for SHA-256 content hashing
- Offer IDs now generated from hash of {sdp, topics} (sorted)
- Removed peerId from hash (inferred from authentication)
- Server generates deterministic IDs for idempotent offer creation
- Updated SQLite and D1 storage implementations
- Removed optional id field from CreateOfferRequest
- Same offer content always produces same ID

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude <noreply@anthropic.com>

CLAUDE.md

@@ -0,0 +1,47 @@
+# Rondevu Server Development Guidelines
+
+## WebRTC Signaling Best Practices
+
+### ICE Candidate Storage
+
+**IMPORTANT: Store ICE candidates as raw JSON without enforcing structure.**
+
+When handling ICE candidates in the signaling server:
+
+- ✅ **DO** store candidates as `JSON.stringify(candidate)` in the database
+- ✅ **DO** retrieve candidates as `JSON.parse(candidate)` from the database
+- ✅ **DO** use generic types like `any` in TypeScript for candidate data
+- ❌ **DON'T** define strict types for ICE candidate structure
+- ❌ **DON'T** validate or modify candidate properties
+- ❌ **DON'T** assume you know what properties clients will send
+
+**Why?** The server is just a relay - it doesn't need to understand the candidate structure. Different browsers and future WebRTC versions may include different properties. By keeping the server agnostic, we maintain maximum compatibility.
+
+### Server Role Filtering
+
+The server MUST filter ICE candidates by role:
+- Offerers receive only answerer candidates (`WHERE role = 'answerer'`)
+- Answerers receive only offerer candidates (`WHERE role = 'offerer'`)
+
+This prevents peers from receiving their own candidates, which would cause connection failures.
+
+## Security
+
+- Always validate authentication tokens before allowing operations
+- Verify ownership before allowing modifications
+- Rate limit API endpoints to prevent abuse
+- Clean up expired offers regularly
+
+## Performance
+
+- Use transactions for batch operations (SQLite)
+- Index frequently queried columns (offer_id, role, created_at)
+- Set appropriate TTLs for offers
+- Implement pagination for large result sets
+
+## Code Quality
+
+- Handle errors gracefully with informative HTTP status codes
+- Log important events for debugging
+- Use TypeScript types for API contracts, but keep data types generic
+- Write tests for critical paths