Fix/approval workflow persistence

[MerlinTheWhiz]

Description

The approval workflow previously relied on a module-level Map as its data store, causing all submissions to be lost on every server restart or cold start. This made the workflow unreliable in production with autoscaling or periodic restarts.

Changes made:

• Created content_approvals table migration with UUID primary key, proper CHECK constraints on content_type and status, TIMESTAMPTZ timestamps, and indexes on status, submitted_by, and submitted_at
• Replaced in-memory Map CRUD operations in the route handler with parameterized SQL queries
• Changed runtime from edge to nodejs (required by the pg database client)
• ID generation now uses the database's built-in gen_random_uuid() instead of the ad-hoc approval-${Date.now()}-${Math.random()...} pattern
• All handlers wrapped in try-catch with proper 500 error responses for database failures
• SQL column aliases used to match the existing ApprovalItem camelCase interface, so the API response shape remains unchanged

Related Issue

Closes #774

Type of Change

• Bug fix
• New feature
• Breaking change
• Documentation update

Checklist

• Code follows project style guidelines
• Self-review completed
• No console errors
• Uses Lucide icons consistently
• Responsive design implemented
• Starknet best practices followed

[drips-wave]

@MerlinTheWhiz Great news! 🎉 Based on an automated assessment of this PR, the linked Wave issue(s) no longer count against your application limits.

You can now already apply to more issues while waiting for a review of this PR. Keep up the great work! 🚀

Learn more about application limits

[RUKAYAT-CODER]

Kindly resolve conflict.