update feedingExpiration logic

[Giorgi217]

Pull Request overview

Fix feeding expiration flow — prevent negative timer and incorrect rejection logic

---

Problem

After the feeding countdown elapsed (~1 hour), the app displayed a negative time and the feeding was not automatically cancelled.
UI elements intended only for the pre-feeding state became visible, while the feeding itself remained active.

Root cause: the expiration flow was incorrectly using the reject feeding operation instead of the dedicated backend expiration mechanism.
This triggered a chain of failures that prevented the feeding from being cancelled.

---

Summary

This PR replaces the incorrect rejection flow with the proper expiration flow aligned with backend logic.

Key fixes:

• Use the correct backend mutation (expireFeeding) for automatic expiration
• Fix incorrect identifiers used in requests
• Remove invalid data sent to GraphQL input
• Rename model and ViewModel methods to reflect actual behavior
• Ensure feeding snapshot is cleared after successful expiration
• Restore correct UI state after feeding ends

---

Root Cause Analysis

1) Wrong operation used (Reject vs Expire)

The app attempted to auto-cancel feeding using:

rejectFeeding

However, backend restrictions allow rejection only by:

• Assigned moderators
• Administrators

As a result, the request consistently failed:

Just assigned moderators or admins can reject the feeding

Automatic expiration must instead use:

expireFeeding

which is designed specifically for timeout scenarios.

---

2) Incorrect identifier usage

The previous implementation used a feeding point ID when fetching the feeding entity, causing the query to return nil and abort the flow.

Correct behavior requires using the feeding ID.

---

3) Invalid GraphQL input payload

The rejection mutation sent malformed data that did not match the backend FeedingInput schema:

• images sent as a single string instead of [String]
• Nullable fields (createdBy, updatedBy, owner) sent as string "null" instead of null
• Mismatch between id and feedingPointFeedingsId
• Default rejection reason inappropriate for expiration scenario

These inconsistencies caused conditional failures inside the Lambda resolver.

---

4) Backend conditional checks

Even with corrected IDs, the rejection mutation still failed due to authorization rules enforced in the resolver transaction.

Expiration must bypass moderator-only constraints and be processed via the dedicated expiration operation.

---

Changes

File	What changed
RejectFeedingMutation.swift	Left intact for manual moderator rejection
ExpireFeedingMutation.swift	Added proper mutation for automatic expiration
HomeModel.swift	Replaced rejection flow with expiration flow
HomeContract.swift	Renamed processRejectFeeding → processFeedingExpiration
HomeViewModel.swift	Updated calls and handlers to use expiration logic
Snapshot handling	Ensures stored feeding snapshot is cleared after expiration

---

🧠 How it works (High level)

• Feeding countdown reaches zero
• App triggers expiration flow
• expireFeeding mutation is sent to backend
• Backend cancels feeding according to timeout rules
• Snapshot is removed
• UI transitions to non-feeding state

---

How to test

Automatic expiration

1. Start a feeding session
2. Wait until countdown completes (or simulate time passage)