[Feedback reliability] Persist an idempotent event queue across app and service failures

## Problem

The mobile feedback queue exists only in a React ref. Events are flushed before another page fetch, at ten items, or after selected explicit actions:

- https://github.com/ACM-VIT/gh-social/blob/49073fc71423aa8e10334158d70ac6d41be1dbc0/src/app/%28tabs%29/home.tsx#L48-L108

Closing/backgrounding the app with a partial batch can lose feedback. The backend then forwards each event independently with `Promise.all` and swallows delivery failures:

- https://github.com/ACM-VIT/gh-social/blob/49073fc71423aa8e10334158d70ac6d41be1dbc0/backend/services/mlService.ts#L119-L127

The database activity path processes events one at a time without a transaction, so a batch can be partially persisted.

## Proposed change

- Give every event a client-generated UUID and timestamp.
- Persist pending events locally and flush on foreground/background, connectivity restoration, and orderly unmount.
- Make the backend batch endpoint idempotent by event ID.
- Store accepted events durably before returning success.
- Forward through an outbox/stream worker with retry and dead-letter visibility rather than best-effort fire-and-forget calls.
- Process database batches transactionally or return per-event status.

## Acceptance criteria

- Restarting the app does not lose pending events.
- Retrying the same batch does not duplicate interactions or counters.
- ML downtime does not lose accepted backend events.
- Partial failures are observable and retryable.
- Tests cover app termination, offline recovery, duplicate delivery, ML timeout, and partial database failure.
- Metrics expose queue depth, oldest pending event, retry count, and dead-letter count.

Start with the queue and flush logic in src/app/(tabs)/home.tsx, then read the backend delivery path in backend/services/mlService.ts and the database activity path. Trace how events move through app shutdown, batching, backend acceptance, ML delivery, and persistence. Done means durable retryable delivery, idempotent retries, observable partial failures, and tests for the listed failure cases and metrics.

Written by the indexing model from the issue text.