add 'send per post' option to the appreciation dialog (draft, needs a BE status field)

[ivannissimrch]

Description

Draft, not for merging. The frontend side is done, but it needs something from the backend, and I'm not sure what the right shape is, so I'm opening this to show what I have and ask.

The problem: an appreciation row only has dateDue and dateDelivery. There is no status, so the frontend figures out what to show by checking which date is set (Appreciation.tsx, entry.dateDelivery ? "received" : "pending"). With two options, that works. With three it breaks. A posted item and a pending item look identical in the database; both have a due date and no delivery date, so when you reopen the dialog, there is nothing to tell them apart and it shows pending.

What I tried: I added a status field on the appreciation on a local be branch, to see if it worked end to end.

// SDK, on ApiAppreciation
status: "received" | "pending" | "post";

That was the field on ApiAppreciation in the SDK, a column on the appreciation table, the same property in sdk-types.json so request validation lets it through, and one line in dtoAppreciation. No route logic changed, GET /volunteer/:id/appreciation, POST /volunteer/:id/appreciation and PATCH /appreciation/:id all pick it up as they are. It worked, and the frontend in this PR is written against it. Until the field is in the published SDK, types.ts widens the type locally, so this does not run against dev or prod.

@arturasmckwcz here is what I did and why. Is a status field the right approach, or would you do it differently?
Can you help me get it built on the backend?

One thing I am unsure about either way: the sent date currently goes into dateDue, because that is the only column that can hold it, which makes the column name a bit off.

Related Issues

Closes #640

Changes

• New Appreciation/types.ts with DeliveryStatus and AppreciationWithStatus, matching the sibling types.ts files in ActivityLog, OpportunityDetails and VolunteerAgents`
• Third delivery option in the dialog, with en/de strings
• Read-back reads status directly instead of an ordered chain of date checks
• getStatusLabel becomes a Record<DeliveryStatus, ...> lookup, so a fourth status will not compile until it is handled
• Third badge colour for the new status

Screenshots / Demos

Checklist

• WITHIN THE SCOPE OF AN ISSUE; No unnecessary files included
• Tests added/updated
• Documentation updated
• CI passes